#466 – Explicitly Assigning Only Some Enumerated Values
December 1, 2011 3 Comments
When defining an enumerated type, you can explicitly assign values to some of the enumerators and let the compiler implicitly assign values to others.
Any enumerated values that you do not explicitly assign a value to will automatically receive a value one greater than the previous value (whether explicitly or implicitly assigned).
For the following enumerated type:
public enum Moods
{
NOMOOD = 0,
Ambivalent,
Happy,
Elated,
Grouchy = 10,
Crabby,
Irate
}
The Ambivalent enumerator will have a value of 1, Happy will be 2, Elated will be 3, Crabby will be 11 and Irate will be 12.
About Sean
2,000 Things You Should Know About C# 
Hi Sean,
Great blog (this and the WPF one too) – I really like the idea of sharing the small tidbits one at a time (as opposed to lengthy tutorial chapters). May be really good for Lunch and Learn sessions at work to bring the more junior developers on board 😉
Now, regarding the recent series of Enum-related posts…
While it is perfectly valid to describe all these intricacies of Enum implementation and usage, I’m wondering if you’re planning to add a word of caution. Yes, I did notice that your blog posts concentrate more on the syntax than on the style… But – IMHO – one of the most important qualities of a good code is its being simple, intuitive, easily readable and comprehensible.
And while – technically – there may be some rare cases that would justify such deviations from the default usage of Enums, I won’t want to see them in a real production code too often. There is certain “hacky” flavour to this. Let’s say, in the ratings example I would rather see a separate definition of Ratings enum, and have some piece of business logic (a Dictionary, maybe?) that would map one enum to the other.
Hope I managed to explain what I was trying to say so incoherently 😉
I disagree. I don’t see how using the framework the way it was designed is hacky. Following best practices is a good idea, but if production code ends up with some edge cases that don’t fall into the “norm”, that’s not a bad thing. I believe the whole point of this blog is to inform us of what is possible. I, for one, would have no personal use for some of the things contained in here, but I wouldn’t ever say that using the framework the way it’s designed to be used is a bad thing.
I agree that that this isn’t a hack and that it would be just fine in production code. I could see wiring up an enum data type with specific values as very useful when doing something like writing code that ultimate interacts with some hardware. E.g. The enum might map to some register in the hardware. Another (fairly common) use case would be to pass data to some legacy system where you need data to align with existing values, but you support a subset of the target system’s data.
While my blog doesn’t try to advise on coding style, I do avoid posting code that is of poor style, or a hack. If there’s a better way to do something that I know of, I’ll try to describe that better way. As with any language, C# has many features that may not be used by 80-90% of developers out there. But while these might be “edge cases” to most developers, the developers that need these features really do need them and will use them in production code.
Having said that, it’s also true that there are sometimes easier vs. harder ways to implement a particular bit of functionality. Which method a developer uses is a result of their skill and experience. Not every developer will find the simplest and most elegant way to do something. And, more importantly, what’s simple and elegant to one person might be confusing to another. Coding style isn’t objective truth, but quite subjective. In the end, the best approach for a team is to do regular code reviews and then have good discussions about things that people disagree on, leading to some basic coding style guidelines.