Quote Originally Posted by stepdragon View Post
That is useful information, but I do have a reason for my question. for example, what if I had saved an integer value to a file, and I load it into my program and use that to compare, or if I just simply had a textbox on the form for the user to unput a number, or along the same lines, used option boxes to set a variable based on which one is selected.
In that instance, where the integer value that represents the values in your enum is relevant, then I would suggest instead a named constant would be better than an enum. There's no practical difference between the the two, but having a constant reflects the intent of your code better, in my opinion.

The enum approach says (to me) "I have values Create, Delete and Rename.".
The constant approach says "I have a value for Create that is 1, a value for Delete that is 2 and a value for Rename that is 3".


And as Nick points out, there is nothing "wrong" with enums. My objection to them is definitely a personal choice - I can't see any use for them other than to violate the Tell Don't Ask principle (Instead of checking the value of the enum and taking different action based on that, you simply tell the object to do whatever it is, and the object performs the correct method due to polymorphism - you can see this happening in my example code: the if blocks have disappeared.) and for scattering related concerns. As ever, YMMV, but enums are so much the "default" choice in this situation in .NET that I like to "over-promote" this approach to counter that.