There are times when an enum's values are important: it is not necessary for them to be unique, they also need to have specific values. In such cases, should the values be explicitly defined, even if they coincide with the defaults? An example:

enum Car {
    DeLorean = 0,
    Lada = 1

Imagine that for whatever reason your application assumes that DeLorean and Lada have those specific values. Incidentally, they are the same as the default values but does that mean it is no longer necessary to use explicit definitions?

Leaving them implicit makes me uneasy. It seams to me that having them explicitly defined is communicating to future programmers that the specific values are important and it helps prevent mistakes like this:

enum Car {

In the example above, another programmer who is not aware of the restriction I mentioned introduces a new enum value and, wanting to keep the code tidy, puts it in alphabetical order. However, DeLorean and Lada now have different numerical values and a potentially silent bug has been introduced.

My reasoning seems correct to me (obviously), but the code review team for a company I used to work with didn't agree. Am I wrong?

  • 2
    It's a judgment call whether to leave in explicit declarations that coincide with defaults that are significant. What's not a judgement call is that this is so subtle a condition that it needs an explanatory/warning comment, badly. Oct 23 '14 at 16:03
  • What was their reason for disagreeing?
    – Rotem
    Oct 23 '14 at 16:03
  • @Rotem I didn't insist too much because there were more important things to be done, but I think my argument didn't have credibility because this was pretty old code that happened to never have caused problems before.
    – Paul
    Oct 23 '14 at 16:07
  • @Rotem They did compromise, however, and the code ended up looking like enum Car { DeLorean = 0, Lada }. I'm not sure that's much better, though.
    – Paul
    Oct 23 '14 at 16:09
  • 4
    If there's a requirement that specific enumeration identifiers map to specific values, then those values should be explicitly specified whether they coincide with the defaults or not. Along with a comment that explains why those values must be specified.
    – John Bode
    Oct 23 '14 at 16:36

This is very much a judgement call, but I would agree with you that explicit values are the way to go, plus a comment at the start explaining the significance of the explicit values.

As an example of a prominent project that is doing it this way, look at Clang's AST serialization. It uses a huge enum to define codes for all of its AST nodes, and the enum has explicit values.

That said, I also sympathize with the opinion of the architecture team that touching old code that works when there's more important things to be done is not the best idea.

I don't like the compromise solution, though. It adds nothing.


If you are storing or transmitting those values then they must be specific. Normally you would define the protocol in a header file shared by both parties. If you have some kind of versioning mechanism then it will not be a big problem. But it is always better to be explicit. I am a fan of 'say what you mean' in the code. It doesn't cost anything and your code is much more readable.

But for internal modules and APIs where the enum values are not stored, the defaults are just fine. It communicates that the value of the enum itself is not important. What is important is what those value mean and the fact that you are using stonger typing to make it clear what the code is using and help to prevent invalid values from vein used.


Consider C++11's enum class; it allows you and your company to eliminate the need for explicit values while removing the subtle bugs enum has.

  • 4
    I don't understand what you mean. How does enum class help? In our case, specific values were required because they were sent through the network.
    – Paul
    Oct 23 '14 at 17:27
  • I see your point; the enum class is strongly typed and cannot be implicitly converted to int for transmission. Your company must design a specification for Car to int mapping; this is what will prevent future mistakes. Oct 23 '14 at 17:30

In new code, if it is part of the system or business requirements that a particular enumeration be equal to a specific value then it should definitely be explicit, commented and documented. Failure to do so invites a maintenance nightmare.

The only factor in your scenario that would delay me from making such enums explicit is the fact that this is old code from a working code base and other tasks might have priority.


With enums, there are three philosophies that work, and one that doesn't

  1. Value agnostic - use default values for ALL options with the underlying values irrelevant
  2. Sequence specific - define the first value leaving all others as increments
  3. Value specific - specify values for ALL options and the value is important (eg comms message IDs)

The one that doesn't

  1. Some specified - some values are specified, and some are not

Option (4) is deprecated by MISRA C (and other such standards)... likewise, the purist in me questions why (2) should be necessary (other than for the default = 0) but there are probably legitimate reasons for this.

Of course, where a value is specified, then there should be adequate documentation to explain why!

IMHO it is quite dangerous to rely on knowing the underlying value of an enumeration, and even more so to assume a sequence - the problems you can get into incrementing and decrementing an enum type...


It is purely a software coding guidelines call (process compliance call).

enumerated values are crux of many algorithms and it should be handled with utmost care. One another option of usage is that it is better that the name of the enumeration constant conveys the value via its name itself to make the understanding clear.

Example :

enum retries {

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.