If you have an enum in your application and you only have a few items, should you for the underlying type to be the smallest possible type?
enum smaller : byte
{
one,
two,
three
};
If you have an enum in your application and you only have a few items, should you for the underlying type to be the smallest possible type?
enum smaller : byte
{
one,
two,
three
};
No. Don't prematurely optimize unless you've proved with a profiler that it's actually a problem.
What would be gained? You'd save a whopping 3 bytes of memory, at the cost of slightly slower execution and less intuitive or readable code. (Reading this, I have to wonder whether pyou actually had a reason for making it a byte, and what that reason might have been. Presumably you went out of your way to use a non-default type for a reason).
If you plan to store millions of these things then yes, saving a few bytes on each may pay off. Otherwise, no.
It's the same reason you don't typically use byte or short instead of int.
You should not assign a certain integer type to enumerations but let the .NET environment figure out the best "size" for the enum. As JaredPar said, if you change the data type, you should definitely check whether it actually helps.
The thing is that 32-bit integers are "natural" on x86 processors because they can be easily align in an optimal fashion.
Relating to best practice:
When you don't have a particular reason for making the enum a type byte, you should leave it as the default.
Any time you use an enum in a switch statement you should have a "default" clause for an invalid enum value. So it doesn't matter if you are checking for 256-NumRealEnumValues or 2^32-NumRealEnumValues. Both will have a default clause that handles all invalid cases.
One reason for explicitly setting the type of the enum, is if you want your enum to correspond to another type in your program and you need to explicitly cast between them.
Changing the type to the smallest fit will not help you with versioning problems either. Unless you have exactly the max size of the enum filled out. By versioning problems I mean when you have a compiled dll using the enum, then you add a new enum value, some code may execute that was not meant to go in the "default" clause of a switch statement.
Relating to efficiency:
No there is no benefit in terms of efficiency to make it a byte.
int is more efficient to use because the cpu on x86 has 32-bit registers. Copying into a register is done 32-bits at a time.
When you use a smaller type, you have to zero out part of the register and copy into the rest of the register's lower order bits.
The only reason to do this is if you are storing or transmitting this value using a defined protocol that demands the field to be of that size.