Is it recommended to suffix all C# enums with "Enum" to avoid naming conflicts?

Question

This stackoverflow question has an interesting discussion on how to avoid giving enums and properties the same names so that you don't have code like this:

public SaveStatus SaveStatus { get; set; }

It seems the accepted answer suggested to use "State" for the enum and "Status" for the property:

public SaveStatus SaveState { get; set; }

But I think this is hard to read and not immediately clear what is what.

Since this enum naming problem is a constant issue, I am considering simply always suffixing my enums with "Enum" so I would have this:

public SaveStatusEnum SaveStatus { get; set; }

SaveStatus = SaveStatusEnum.Succeeded;

Does anyone do this? Happy with it? Solved this issue in another way?

Answer 1

Does the .net Framework use Enum as a Suffix? No. That's why I do not use it either.

Instead, I use words like Option (or Options if it's a Flags-Enum), Mode or similar.

public SaveStatusMode SaveStatus { get; set; }
public SaveStatusOption SaveStatus { get; set; }
public SaveStatusVariant SaveStatus { get; set; }

Answer 2

Microsoft's .NET naming guidelines don't give any such recommendation.

Why would you avoid giving enums and properties the same names? This:

public SaveStatus SaveStatus { get; set; }

works just fine, is readable, and is very discoverable and usable.

Answer 3

From the MSDN page for Property naming guidelines:

"Consider creating a property with the same name as its underlying type. For example, if you declare a property named Color, the type of the property should likewise be Color."

I'd take that as a "no" :)

Edit:

If you dislike using the fully qualified name inside the class that declares the property, you can work around it:

using SaveStatusEnum = MyNamespace.SaveStatus;
...
SaveStatus = SaveStatusEnum.SomeValue;

That way you can keep the enum name without the suffix, and limit the naming oddity to just that one class. :)

Answer 4

A kind of suffix are used for some types of classes, like xxxException and xxxAttribute classes, but suffixes are not widely used. For example, a class that implements IEnumerable is not named MyListEnumerableClass, but just MyList.

Instead of inventing a standard suffix that clutters up the names, try to make up names that make sense in the particluar situation.

Answer 5

If defining the property in the manner that you have it surely makes no difference whether the names are the same or not. I would say that it is probably clearer to use in that manner.

Answer 6

I know my suggestion goes against the .NET Naming conventions, but I personally prefix enums with 'E' and enum flags with 'F' (similar to how we prefix Interfaces with 'I'). I really do not understand why this is not the convention. Enums/Flags are a special case like Interfaces that will never change their type. Not only does it make it clear what it is, it's very easy to type in intellisense since the prefix will filter most other types/variables/etc, and you won't have these naming clashes.

And that would also solve another problem where for examples in WPF they use static classes like enums (e.g. FontWeights) that have pre-defined instances of types but you would not know if you don't search for it. If they just prefixed them with 'E', all you would have to do is type on character to find these special static classes.