There are some related questions here and here, but they didn\'t really give me satisfactory answers. The problem is that enums nested in a class in C# cannot have the same name
It would also be nice to know why this is disallowed. Maybe Eric Lippert or someone could chime in on the decision to forbid it?
The point of the rule is to ensure that there is no ambiguity within the class when looking up a name. Certain regions of code are designated as defining a 'declaration space'. The fundamental rule of declaration spaces is no two things declared in the same declaration space have the same name (except for methods, which must differ by signature, not name.)
Making exceptions to this rule just makes things more confusing, not less confusing. I agree that it is vexing that you cannot have a property and an enum of the same name declared in the same declaration space, but once you start making exceptions then it just gets to be a mess. It's usually a nice property that a name uniquely identifies a method group, type parameter, property, and so on.
Note that this rule applies to things declared in a declaration space, not things used in a declaration space. It is perfectly legal to say "public Suit Suit { get; set; }" provided that the type Suit is not declared in the same declaration space as the property. When someone says "Suit.X", figuring out whether X is on the type (that is, X is a static member) or the property (that is, X is an instance member) is a bit tricky. See my article on how we do that for details:
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
I would agree with moving the enum definition to a separate place. Currently, the enums are only visible through card, so if you wanted to check for an ace, you would have to do
if (card.CardSuit == Card.Suit.Ace) { } //need different name for Suit field
Where if you moved it to a separate definition, you could do this if you made it global:
if (card.Suit == Suit.Ace) { } //no naming clashes, easier to read
I prefer to name enums using a noun followed by Options. In your case:
SuitOptions
RankOptions
After all, the enum is just a set of possible options, right?
You will have then:
myCard.Suit = Card.SuitOptions.Clubs;
Which in my opinion makes sense and you are still able to know when viewing the text whether is then enum or property.
It't interesting to see that while the Microsoft Naming Guidelines say you should use a singular name for most enums and plural names for bit fields, the code sample for the enum keyword does use a plural name!
enum Days { Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };
I would move the enumerations outside the class definition and use the namespace to indicate that they relate to cards. I generally don't like enums nested inside classes. You're right about the plurality, though: singular for regular enums, plural for flags enums.
Your enums are basically data types which you have defined. You would not use 'int' or 'string' as a member name, so I think it is an equally bad idea to use the your enum names and member names in your case.