tags:

views:

816

answers:

4

When using a class that has an enum property, one usually gets a naming conflict between the property name and the enum type. Example:

enum Day{ Monday, Tuesday, ... }

class MyDateClass
{
   private Day day;

   public Day Day{ get{ return day; } }
}

Since only flags enums should have plural names, naming the enum "Days" is not the way to go for a non-flag enum. In the above example you could use some variation like "WeekDay" for either the enum or the property. But in the general case there are no good variations like that so you end up using properties like "FooMode" or "BarKind" for an object with enum properties of Foo and Bar type. Not so elegant.

How do you usually name enums and properties in this scenario?

+4  A: 

So long as the enumeration isn't nested within MyDateClass, I don't see that that's a problem. It's far from uncommon (in my experience) to have a property with the same name as the type it returns. I'll see if I can find some examples in the framework...

EDIT: First example: DateTimeOffset.DateTime (not an enum, but that's somewhat irrelevant)

Jon Skeet
It is quite common for web service emitted classes.
leppie
A: 

I agree with Jon, I don't see it as a problem. I have written code like this, although I would say it's fairly uncommon without running in to any issues, even code that is marked as CLSCompliant(true).

Scott Dorman
+12  A: 

There is no conflict. In fact, the .NET Framework style guide encourages you to do this, e.g. if you have a class that has a single property of a type (no matter if enum or class), then you should name it the same. Typical example is a Color property of type Color. It's fine, unless there are two colors - in that case both should add something to the name (i.e. BackColor and ForeColor, instead of Color and BackColor).

OregonGhost
The canonical example of this in my mind is DbCommand.CommandType being of type CommandType.
Rory MacLeod
+1  A: 

Thanks for the quick responses. Another question: why is it not recommended to nest public enums, and how do you resolve the naming issues if you want to nest public enums?

class Vehicle
{
  enum Kind{ Car, Bike }

  public Kind Kind{ get{ return ... } }
}

class Meal
{
  enum Kind{ Dessert, MainCourse }

  public Kind Kind{ get{ return ... } }
}

In the scenario above, given that Meal and Vehicle share the same namespace, I can't move "Kind" outside either of the classes without renaming it MealKind and VehicleKind respectively. I like the look of

myVehicle.Kind = Vehicle.Kind.Car

But that is not what the guidlines recommend. What would be the best practice here? Never to use nested public enums and instead name them VehicleKind etc.?

AndersF
It wont work in a nested scenario. Then there is clearly a name clash. I dont even think using a 'using' alias will work in this case.
leppie
Nested enums make the code longer and are closely tied to the class. Oh, and in your example, you might want to derive Car and Bike from Vehicle and Dessert and MainCourse from Meal, so no need for an enum :)
OregonGhost
Assuming you need the enum (i.e. the kind must be used as a value, not a subclass), isnt it nicer to have public nested enums than to have a lot of enums prefixed with the class name like VehicleKind? For example when renaming the class, all enums belonging only to that class must be renamed...
AndersF
I usually use nested enums only if it is for internal purposes, partially because of the naming conflict that arises from the enum being nested, partially because it just doesn't feel right if you use such an enum. As I already said, nesting means tight coupling, while external enums can be re-used.
OregonGhost
Suppose you have a Person class, which has a PreferredVehicleKind property. With nesting, Person needs to know Vehicle, so it is dependent on it. Without nesting, Person just needs to know VehicleKind. When I see some kind of "kind" in code, I always smell some kind of OO violation. Maybe just me.
OregonGhost
But would it be bad OO to have a property PreferredVehicleKind in the class Person, which has type Vehicle.Kind rather than VehicleKind? It is tightly coupled to the class Vehicle either way?
AndersF
No, it's not. If VehicleKind is an external enum, you don't need to know Vehicle just to use VehicleKind, therefore Person is in that case not coupled to Vehicle in any way, in contrast to using the nested enum. You don't need to be able to drive a car to say you prefer cars over bikes, do you? :)
OregonGhost