views:

694

answers:

6

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?

+4  A: 

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; }
Michael Stum
+6  A: 

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.

Joe White
But then in my constructor I have to have a huge namespace qualifier: SaveStatus = TestingDelegateCommandSave.ViewModels.SaveStatus.NotApplicable; otherwise intellisense thinks I mean "SaveStatus" the property. I have the enum defined in my class file since it is only used for my class, hence the naming conflict with the property which is why I'm looking for another convention of naming enums, to avoid this.
Edward Tanguay
I use the SaveStatus SaveStatus all the time. Since the one is a property, I think is more readable than doing changing the name to SaveState. I would never use the enum stuff.
David Basarab
@Edward: No, you don't need a namespace qualifier, at least not in C#. "SaveStatus = SaveStatus.NotApplicable" works just fine.
Joe White
+18  A: 

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. :)

Rytmis
Yes, but this causes naming conflicts when I have the enum in my class file. I have to always use the full namespace when I want the enum since VisualStudio intellisense always thinks I mean the property. SaveStatus = TestingDelegateCommandSave.ViewModels.SaveStatus.NotApplicable;
Edward Tanguay
OK, I take that back, it works with intellisense (I had some old ...Enum code in there). Nice. This was the answer I was looking for, something decisive. I'm naming my enums the same as my properties from here on out.
Edward Tanguay
Actually, the compiler may complain about it too -- I just tried with an example in my real-life project. If that happens, you can work around it with a using statement (I updated my answer with an example).
Rytmis
If VisualStudio is ok with it, then I'm ok with it: as I type "SaveStatus = SaveStatus.NotApplicable", intellisense first offers me the property and then the enum.
Edward Tanguay
The language has a number of carefully designed rules to enable this scenario (which we call "the Color Color scenario") but indeed, there are situations in which ambiguities are unavoidable. For details, see section 7.4.5.1 "Identical simple names and type names" of the C# 3.0 spec.
Eric Lippert
+4  A: 

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.

Guffa
+1  A: 

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.

ChrisBD
+1  A: 

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.

Hermann