16

When creating a new enum in C#, is it a good practice to have null member?

If yes, do you give it the value of 0 by default? Would you call the null member Null or NULL? Do you strictly believe in Null or you don't have any problem with calling it something other than null. For instance None. Can you elaborate on your answer?

user2864740
  • 60,010
  • 15
  • 145
  • 220
MHOOS
  • 5,146
  • 11
  • 39
  • 74

2 Answers2

23

UPDATE: The widely accepted answer on the linked duplicate favors the use of nullable types instead of defining a "null"/"none"/0 member. The FxCop rule described below existed before Nullable types did.

So instead of:

var myEnum = SomeEnumType.None;

You would defined it as null using a Nullable value type instead:

SomeEnumType? myEnum = null;

I still hold that a None member of a [Flags] enum can be useful.

Previous answer:

There's a design rule in Visual Studio, CA1008, that provides some insight into your question. The description of the rule is (styling mine):

The default value of an uninitialized enumeration, just like other value types, is zero. A non-flags−attributed enumeration should define a member that has the value of zero so that the default value is a valid value of the enumeration. If appropriate, name the member 'None'. Otherwise, assign zero to the most frequently used member. Note that, by default, if the value of the first enumeration member is not set in the declaration, its value is zero.

If an enumeration that has the FlagsAttribute applied defines a zero-valued member, its name should be 'None' to indicate that no values have been set in the enumeration. Using a zero-valued member for any other purpose is contrary to the use of the FlagsAttribute in that the AND and OR bitwise operators are useless with the member. This implies that only one member should be assigned the value zero. Note that if multiple members that have the value zero occur in a flags-attributed enumeration, Enum.ToString() returns incorrect results for members that are not zero.

There is also an Enum Design article that makes the following points:

  • √ DO provide a value of zero on simple enums. Consider calling the value something like "None." If such a value is not appropriate for this particular enum, the most common default value for the enum should be assigned the underlying value of zero.
  • X AVOID using flag enum values of zero unless the value represents "all flags are cleared" and is named appropriately, as prescribed by the next guideline.
  • √ DO name the zero value of flag enums None. For a flag enum, the value must always mean "all flags are cleared."

Based on the above, I would say that yes, it is good practice, especially when you have a [Flags] enum.

Chiramisu
  • 4,687
  • 7
  • 47
  • 77
Cᴏʀʏ
  • 105,112
  • 20
  • 162
  • 194
  • I just updated NuGet packages, and now I get a CA1069 - Enums should not have duplicate values. Specifically, the error message says "The enum member 'None' has the same constant value '0' as member 'None'. Is there some sort of None baked into the underlying enum type now? – Bob.at.Indigo.Health Nov 29 '20 at 01:50
  • Two minutes later: I saw it, I commented on it... and now the warning is gone. Something weird in Visual Studio 2019 and/or the NuGet package that does the FxCop magic... – Bob.at.Indigo.Health Nov 29 '20 at 01:55
7

The Framework Design Guidelines suggest that you should:

DO provide a value of zero on simple enums.
Consider calling the value something like "None". If such a value is not appropriate for this particular enum, the most common default value for the enum should be assigned the underlying value of zero.

Example:

 public enum Compression {
      None = 0,
      GZip,
      Deflate
 }

They also advise against using sentinal values like First and Last, since they are confusing for users.

These are only guidelines and there may be competing concerns that override this advice, like compatibility with existing libraries or usage patterns.

Mike Zboray
  • 39,828
  • 3
  • 90
  • 122