Reputation: 744
Why do a lot of people do enums this way:
public enum EmployeeRole
{
None = 0,
Manager = 1,
Admin = 2,
Operator = 3
}
instead of just doing:
public enum EmployeeRole
{
None,
Manager,
Admin,
Operator
}
Are there advantages?
Upvotes: 7
Views: 201
Reputation: 156654
It helps avoid having these supposedly constant values change just because somebody rearranges the class. Say you have a new employee that decides "None" should go at the back of the list:
public enum EmployeeRole
{
Manager,
Admin,
Operator,
None
}
Well, if you were only ever accessing these values directly from EmployeeRole.Whatever, that's not a huge deal. But most enums I've seen get converted at some point to an integer value when they're persisted in a database. That means all your "None" elements in storage just got converted to "Manager"s.
The same problem would arise if someone merely inserted a new EmployeeRole between, say, Admin and Operator.
Another advantage arises when you don't consider there to be an appropriate "default" value for your enum. For example, if somebody forgot to map an EmployeeRole field in the ORM, objects pulled from the repository would always appear to have None
role (0 is always the default for enums). Depending on how your software handles None
, this sort of bug may go uncaught for some time. But if you do this:
public enum EmployeeRole
{
Manager = 1,
Admin = 2,
Operator = 3
}
... and then combine it with fail-fast techniques, you can quickly catch errors where an invalid "0" value was provided:
public RightsManager GetByEmployeeRole(EmployeeRole role)
{
Require.That(role.IsDefined()); // throws an exception if role is not defined.
// find the rights manager for this role.
}
Upvotes: 0
Reputation: 4028
I see two main advantages:
Upvotes: 0
Reputation: 171864
For example, when you store values in a database, it's advised to have a fixed mapping between numbers and symbolic values. If you don't specify the numeric values explicitly, the compiler will number them sequentially, so if you insert a new one, you'll have a mismatch.
Upvotes: 0
Reputation: 241771
Are there advantages?
Maintainability. Let's say these integer values end up persisted in a database. You don't want to add a new value to the enum in the future and have the values change because you insert a value in a way that shifts the unspecified values.
Clarity. Explicitness is a good thing. Let's say again we're reading integers out of a database from some legacy application. So the codes already have a specific meaning, and we want to explicitly line up with them. We could say
public enum EmployeeRole {
None,
Manager,
Admin,
Operator
}
and maybe that lines up exactly with the legacy specification or we could say
public enum EmployeeRole {
None = 0,
Manager = 1,
Admin = 2,
Operator = 3
}
and now it is easier to read whether or not we line up with the legacy specification.
Upvotes: 4
Reputation: 47058
It is useful when you have a contract elsewhere. If you store the enum in a database you want to type the numbers explicitly to be sure you don't accidentally renumber the enum by inserting a new item in the middle.
Upvotes: 2
Reputation: 37543
It explicits defines a value rather than letting the compiler handle it at compile time. In the case you provided, it really serves no point other than being readable and and well-defined. It doesn't hurt anything and results in the same MISL as not explicitly setting them. However, in cases where your enums relate to specific values that are not auto-incremented as the above case is, this kind of explicit definition comes in very handy.
public enum MyEnum
{
First = 1,
Second = 2,
Eleventh = 11
}
Upvotes: 1