Pros and Cons explicitly setting enum field's values

Is it preferable to explicitly set enum's fields instead of just defining their names? E.g. any pros and cons for Enum1 vs Enum2?

Enum1:

enum SomeEnum
{
   Something1 = 0,
   Something2 = 1
}

Enum2:

enum SomeEnum
{
   Something1,
   Something2
}

P.S. This question doesn't relates t开发者_高级运维o enums that would be stored in database, which is requires to set values explicitly.

Edit: Say all values are 0, 1, etc... They are not negative or something.

---

Enum1 and Enum2 compile to the same enumeration. So from a programming standpoint, there is no difference. From a maintenance standpoint, there may or may not be issues.

On the one hand, declaring explicit values is absolutely required for a [Flags] enum; and they need to be values at powers of 2.

On the other hand, explicit values can reduce maintainability simply by creating values that cannot or should not be changed in the future.

In general, I prefer to not declare explicit values unless the values themselves are significant for some reason -- if your C# enumeration is, for example, wrapping a C enumeration.

---

it's useful when you need to have negative values

enum
{
  Error = -1,
  Success = 0,
  Something1, 
  Something2,
};

---

You would use Enum1 if you need values that are not contiguous.

enum Colors 
{ 
    Red = 1, 
    Green = 2, 
    Blue = 4, 
    Yellow = 8 
};

Also, explicitly setting the numbers is easier to read, and adding a value in the middle doesn't change any of the other values.

---

Its useful to explicitly set the values if the have some meaning outside of your program. For example, an application might write a log file that uses a Severity value that you can use for filtering the log file later. Setting the values explicitly in an Enum means you can use the Enum in your code (e.g. Critical, Error, Warning) instead of the numeric values. In the log file you would want the numeric value written for easier sorting.

I've also seen an enum used to represent values in a database reference table. In that case, you want to make sure that the items in the enum always have the same value as the database table and that inserting a new item in the middle of the enum doesn't mess up the values.

---

Use example 1 if you actually need to have numbers (i.e. you need to know that something2 actually equals 2)

For all other options do not use numbers. that way, you could happily add additional items to your enum without breaking any other code with may refer to your enum.

---

I've run into problems serializing enums that don't contain the value 0, when using them over a web services interface.

---

it depends on what you are doing with you enums. If you are using them with [Flags] then you MUST set them explicitly. if you are not, then either way works from a coding standpoint. however, for readability or (as mentioned) use in a database situation, then you should explicitly set them. Another consideration is the coding standards of your workplace, and, serialization as well.

---

Enum 1 is also necessary when you need to use flagged enums: http://weblogs.asp.net/wim/archive/2004/04/07/109095.aspx

---

If all you want is a set of int-like constants whose values aren't important, use the default. If the values matter then set them.

An example of values that matter is creating values for bit flags that can be set something like this:

> enum 
{
    flag1 = 1;
    flag2 = 2;
    flag3 = 4;
};

func1(flag1 | flag3);

---

Consider also that integer-backed enums will have a default value of default(int) (or, zero) if their value has not been set, therefore when using implicitly numbered enums it can be difficult to distinguish enum values which have not been set from enum values which have been deliberately set to the first option. This might make a good argument for explicitly assigning integer values to your enum values, with a starting integer other than zero. Unless of course you make your first value "NotAssigned" or some such.