The only thing enum really does is make your code more legible. If you create your own "cheatsheet" by manually writing down what types correspond to which numbers, you can use my example verbatim.
Some of what I say below may depend on the implementation of enumerations on a per language basis. My point of reference here is C/C++/ObjC/to a lesser extent,Java etc.
I think you're underestimating the importance of this and highly advise against this approach. Encoding the meaning in an enumeration name is potentially its greatest strength. Also, in languages like C or C++, a popular but awful way of doing things is using macros but you lose important things like type safety as well as proper debugger support.
EG (using C code):
Code:
int rawIntConsultYourLookupTable = 5;
#define SOME_VALUE 10
int testy = SOME_VALUE;
typedef enum
{
SE_VALUE_A,
SE_VALUE_B
} SomeEnum_t;
SomeEnum_t anEnum = SE_VALUE_A;
Assuming all of that is in some main function in C and you can actually compile/run the program, lets say you're using the visual studio debugger and you step through the above code. Set a breakpoint after the assignments and check the values of these variables.
What does the VS debugger show for the value of rawIntConsultYourLookupTable after the assignment?
5, and you have ZERO point of reference if you lose said lookup table or if you change it and forget to update the reference, or even more poisonous, your reference is straight wrong. You can't even see any context in your assignments.
What does the VS debugger show for the value of testy after the assignment?
10, but at the very least you can see some context at your assignment locations, assuming of course that you're disciplined enough to always use macros AND you also make damn sure that no invalid values get assigned (cause the compiler can't automatically help you with that matter, so you'll have to write extra code to guarantee valid assignments).
What does the VS debugger say for the value of anEnum after the assignment?
SE_VALUE_A(0)
Keep in mind that you're often working across files - you may not see the assignment to the variable as easily as you can above so rather than having to consult some weird number chart, you can see clearly the meaning in the name.
Enums also restrict assignment to valid values. If you just write down what number corresponds to what, in the long term it's going to be hard to understand, hard to change (especially if you have many points of reference), and also very error prone. If your code assumes a certain range of values, and somehow an invalid number gets assigned to the variable, then you're in for a fun debugging session.
A common pattern for enums in C/C++ is to use switch tables to implement logic specific to certain types an enum maps to. Most compilers (that I've used) allow you to make switches that don't handle every value declared in the enumeration as an error. What does this mean? If you add to an enumeration, say by introducing another character type, then rather than having to manually look up every single switch in your code that works with said enum (while potentially missing some switch statements, and thus potentially introducing a bug into your code), you can just hit the compile button and it will error out and tell you exactly where you need to add cases.
This advice is partially language specific, but even if legibility were your ONLY concern (say if we're dealing with a language without any type safetyp it's STILL (IMO) worth it to use enums in many cases.
Of course there are certain things that would be stupid and clumsy to enums with but something like character types is begging for enums (at least if you're not handling it polymorphically or something)