18

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?

Community
  • 1
  • 1
Edward Tanguay
  • 189,012
  • 314
  • 712
  • 1,047
  • One of the points of MS IDE for developing in DOTNET is to remove problems such as this. I would even say the IDE is an integral part of DOTNET. – Itay Moav -Malimovka May 28 '09 at 12:35
  • 1
    I do that and I am happy with it. I used to avoid it but it caused me problems in real code. When you look at one line of code it seems reasonable to have SaveStatus SaveStatus { get; set; }. When you're in a class with hundreds of lines and resharper keeps confusing the two, it's annoying and confusing. – JohnOpincar May 28 '09 at 13:04
  • 1
    Yes, but that's a ReSharper bug, not a Visual Studio or a compiler problem. Tell the ReSharper team to fix their bug. http://www.jetbrains.net/jira/browse/RSRP-83171 – Joe White May 28 '09 at 20:24

7 Answers7

27

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

FishBasketGordo
  • 22,904
  • 4
  • 58
  • 91
Rytmis
  • 31,467
  • 8
  • 60
  • 69
  • 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 May 28 '09 at 12:48
  • 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 May 28 '09 at 12:54
  • 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 May 28 '09 at 12:56
  • 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 May 28 '09 at 13:03
  • 4
    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 May 28 '09 at 15:54
8

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
  • 177,530
  • 117
  • 400
  • 535
6

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
  • 94,807
  • 60
  • 220
  • 330
  • 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 May 28 '09 at 12:46
  • 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 May 28 '09 at 12:46
  • @Edward: No, you don't need a namespace qualifier, at least not in C#. "SaveStatus = SaveStatus.NotApplicable" works just fine. – Joe White May 28 '09 at 17:08
  • Microsoft's .NET naming guidelines recommend not using "Enum" as a suffix. http://msdn.microsoft.com/en-us/library/4x252001(v=vs.71).aspx – jessegavin Apr 26 '12 at 17:31
  • @jessegavin, I know, that's exactly what I said in my answer. – Joe White Apr 27 '12 at 03:46
  • Oh, I guess I read your first sentence to mean "Microsoft is silent on the issue". My bad. You're right. – jessegavin Apr 27 '12 at 14:52
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.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
3

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.

  • Probably the same reason we don't prefix Classes with `C` and structs with `S`. With modern editors, modifying variables or types for distinguishing characteristics is just superfluous. – Erik Philips Jan 15 '20 at 23:40
1

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
  • 9,104
  • 3
  • 22
  • 35
0

I recommend the MS guidelines. And it's always ugly coding to read something like 'FooEnum' in code ;)

Rudolf Stepan
  • 11
  • 4