Do enums have a limit of members in C#?

Question

I was wondering if the enum structure type has a limit on its members. I have this very large list of "variables" that I need to store inside an enum or as constants in a class but I finally decided to store them inside a class, however, I'm being a little bit curious about the limit of members of an enum (if any).

So, do enums have a limit on .Net?

Answer 1

Yes. The number of members with distinct values is limited by the underlying type of enum - by default this is Int32, so you can get that many different members (2^32 - I find it hard that you will reach that limit), but you can explicitly specify the underlying type like this:

enum Foo : byte { /* can have at most 256 members with distinct values */ }

Of course, you can have as many members as you want if they all have the same value:

enum { A, B = A, C = A, ... }

In either case, there is probably some implementation-defined limit in C# compiler, but I would expect it to be MIN(range-of-Int32, free-memory), rather than a hard limit.

Answer 2

You could theoretically use int64 as your base type in the enum and get 2^63 possible entries. Others have given you excellent answers on this.

I think there is a second implied question of should you use an enum for something with a huge number of items. This actually directly applies to your project in many ways.

One of the biggest considerations would be long term maintainability. Do you think the company will ever change the list of values you are using? If so will there need to be backward compatibility to previous lists? How significant a problem could this be? In general, the larger the number of members in an enum correlates to a higher probability the list will need to be modified at some future date.

Enums are great for many things. They are clean, quick and simple to implement. They work great with IntelliSense and make the next programmer's job easier, especially if the names are clear, concise and if needed, well documented.

The problem is an enumeration also comes with drawbacks. They can be problematic if they ever need to be changed, especially if the classes using them are being persisted to storage.

In most cases enums are persisted to storage as their underlying values, not as their friendly names.

enum InsuranceClass
  {
   Home,     //value = 0 (int32)
   Vehicle,  //value = 1 (int32)
   Life,     //value = 2 (int32)
   Health    //value = 3 (int32)
  }

In this example the value InsuranceClass.Life would get persisted as a number 2.

If another programmer makes a small change to the system and adds Pet to the enum like this;

enum InsuranceClass
  {
   Home,     //value = 0 (int32)
   Vehicle,  //value = 1 (int32)
   Pet,      //value = 2 (int32)
   Life,     //value = 3 (int32)
   Health    //value = 4 (int32)
  }

All of the data coming out of the storage will now show the Life policies as Pet policies. This is an extremely easy mistake to make and can introduce bugs that are difficult to track down.

The second major issue with enums is that every change of the data will require you to rebuild and redeploy your program. This can cause varying degrees of pain. On a web server that may not be a big issue, but if this is an app used on 5000 desktop systems you have an entirely different cost to redeploy your minor list change.

If your list is likely to change periodically you should really consider a system that stores that list in some other form, most likely outside your code. Databases were specifically designed for this scenario or even a simple config file could be used (not the preffered solution). Smart planning for changes can reduce or avoid the problems associated with rebuilding and redeploying your software.

This is not a suggestion to prematurely optimize your system for the possibility of change, but more a suggestion to structure the code so that a likely change in the future doesn't create a major problem. Different situations will require difference decisions.

Here are my rough rules of thumb for the use of enums;

1. Use them to classify and define other data, but not as data themselves. To be clearer, I would use InsuranceClass.Life to determine how the other data in a class should be used, but I would not make the underlying value of {pseudocode} InsuranceClass.Life = $653.00 and use the value itself in calculations. Enums are not constants. Doing this creates confusion.
2. Use enums when the enum list is unlikely to change. Enums are great for fundamental concepts but poor for constantly changing ideas. When you create an enumeration this is a contract with future programmers that you want to avoid breaking.
3. If you must change an enum, then have a rule everyone follows that you add to the end, not the middle. The alternative is that you define specific values to each enum and never change those. The point is that you are unlikely to know how others are using your enumerations underlying values and changing them can cause misery for anyone else using your code. This is an order of magnitude more important for any system that persists data.
4. The corollary to #2 and #3 is to never delete a member of an enum. There are specific circles of hell for programmers who do this in a codebase used by others.

Hopefully that expanded on the answers in a helpful way.