Naming Conventions for Enumerations

[orekinbck]

Hi There

What convention do you use when naming an enumeration and variables
that use the enumeration?

I like plural/singular, for example:

public class Example
{
public enum VehicleTypes { Car, Truck, Motorbike };
static VehicleTypes VehicleType = VehicleTypes.Car;
}

But CodeAnalysis/FXCop complains about it:

CA1717 : Microsoft.Naming : If the name 'VehicleTypes' is plural,
change it to its singular form

It does not complain about:

public class Example
{
public enum VehicleType { Car, Truck, Motorbike };
static VehicleType MyVehicleType = VehicleType.Car;
}

But I don't think it reads well

Bill

 

[notifications]

What convention do you use when naming an enumeration and variables

that use the enumeration?

Here is a start:
http://msdn.microsoft.com/library/d...html/cpconenumerationtypenamingguidelines.asp

Furthermore, have a look at :
http://msdn.microsoft.com/library/d...ef/html/cpconNETFrameworkDesignGuidelines.asp



HTH
Erick Sgarbi
www.blog.csharpbox.com

 

[Oliver Sturm]

CA1717 : Microsoft.Naming : If the name 'VehicleTypes' is plural,
change it to its singular form

It does not complain about:

public class Example
{
public enum VehicleType { Car, Truck, Motorbike };
static VehicleType MyVehicleType = VehicleType.Car;
}

The reason why the complaint is shown is because plural enum type names
are supposed to be used with enums that have the FlagsAttribute.
Consider these two:

enum VehicleType {
Car, Truck, Motorbike
}

[Flags]
enum JobFunctions {
Janitor, Teacher, HeadOfSchool
}

Now in a class of a Person, you might have:

class Person {
VehicleType vehicleType;
JobFunctions jobFunctions;
}

With this naming convention you can see from the type names that the
person will have just one assigned vehicle type, but it's possible to
have multiple job functions.


Oliver Sturm

 

[orekinbck]

Thanks Erick & Oliver

Bill

 

[Guest]

I have the following issue:

public enum EmployeeStatus
{
Active,
Retired,
LOA,
InActive
}

This enum is a member of class EmployeeBE (BE = Business Entity)

public class EmployeeBE
{
public string name;
private EmployeeStatus employeeStatus

public EmployeeStatus EmployeeStatus
{
get {return employeeStatus;}
set {employeeStatus = value;}
}
}

Clearly I have a problem in the Property EmployeeStatus because the property
name matches exactly the type. I could change either one, but both are
logical values. What I'm looking for is the Best Practice for this.

Can anyone make a recommendation that would be considered an industry best
practice?

Thanks

 

[Matt]

I have the following issue:

public enum EmployeeStatus
{
Active,
Retired,
LOA,
InActive
}

This enum is a member of class EmployeeBE (BE = Business Entity)

public class EmployeeBE
{
public string name;
private EmployeeStatus employeeStatus

public EmployeeStatus EmployeeStatus
{
get {return employeeStatus;}
set {employeeStatus = value;}
}
}

Clearly I have a problem in the Property EmployeeStatus because the property
name matches exactly the type. I could change either one, but both are
logical values. What I'm looking for is the Best Practice for this.

Can anyone make a recommendation that would be considered an industry best
practice?

My personal preference, and the one I used at various companies
(including some large place in Redmond, what IS that place called? LOL)
was to use an underscore for the type and a plain name for the
property:

public _EmployeeStatus EmployeeStatus

Matt

 

[Daniel O'Connell [C# MVP]]

My personal preference, and the one I used at various companies
(including some large place in Redmond, what IS that place called? LOL)
was to use an underscore for the type and a plain name for the
property:

public _EmployeeStatus EmployeeStatus

Yuck. Underscores in type names now?

The framework simply uses the same name twice, so its what people will
expect and be used to. Its not like you access the members of an enum member
anyway.

Another note, EmployeeStatus could simply be changed to status, since
Employee.Status tells you exactly the same information as
Employee.EmployeeStatus.

 

[Oliver Sturm]

Clearly I have a problem in the Property EmployeeStatus because the property
name matches exactly the type. I could change either one, but both are
logical values. What I'm looking for is the Best Practice for this.

This shouldn't be any problem at all, why do you think it is? You only
have a problem if you put the enum _into_ the class, as opposed to the
same namespace level as the class, because then the identifier is really
ambiguous within the class.



Oliver Sturm

 

[Matt]

Yuck. Underscores in type names now?

Depends on the type name. I don't think of an enumeration as something
people are going to use in place, its more of a placeholder for the
real value, which is the actual enumerated value.

The framework simply uses the same name twice, so its what people will
expect and be used to. Its not like you access the members of an enum member
anyway.

Entirely true, but it still drives me nuts. It *does* work, it *is*
legal, but there's something about it that makes me feel the compiler
is going to choke all over it.

Another note, EmployeeStatus could simply be changed to status, since
Employee.Status tells you exactly the same information as
Employee.EmployeeStatus.

Agreed, and a much better solution than mine. Of course, it only works
in this particular case. And status is complicated in many classes.
Still, I vote for your choice.

Matt

 

[Guest]

Depends on the type name. I don't think of an enumeration as something
people are going to use in place, its more of a placeholder for the
real value, which is the actual enumerated value.


Entirely true, but it still drives me nuts. It *does* work, it *is*
legal, but there's something about it that makes me feel the compiler
is going to choke all over it.


Agreed, and a much better solution than mine. Of course, it only works
in this particular case. And status is complicated in many classes.
Still, I vote for your choice.

Matt

Thanks for the input. In this case, shortening the property to Status will
work and is better, but in general, the old C++'re / VBer in me says that
some of the new Best Practices in C# are going to cause issues like this.
We're having to go through and tag all our Business Entities with a BE suffix
now to avoid collisions with instances of the classes, and properties on
other collections. How disturbing a name is EmployeeCollectionBE? If a
Workgroup has a collection of Employees it would have a variable named
EmployeeCollection of type EmployeeCollection which is the same boat as the
enum, so we add the suffix.

One other question... why is it okay to suffix EmployeeCollection with
Collection, but it's not okay to prefix EmployeeStatus with an e for enum and
get eEmployeeStatus (much clearer in my opinion). Isn't a collection a type
and therefore violating the rule on not revealing type in the variable name?

 

[Daniel O'Connell [C# MVP]]

Thanks for the input. In this case, shortening the property to Status
will
work and is better, but in general, the old C++'re / VBer in me says that
some of the new Best Practices in C# are going to cause issues like this.
We're having to go through and tag all our Business Entities with a BE
suffix
now to avoid collisions with instances of the classes, and properties on
other collections. How disturbing a name is EmployeeCollectionBE? If a
Workgroup has a collection of Employees it would have a variable named
EmployeeCollection of type EmployeeCollection which is the same boat as
the
enum, so we add the suffix.

Well, the first thing is *WHY* are you suffixing everything? Properties and
Variables should not be suffixed with Collection:

public class WorkGroup
{
public EmployeeCollection Employees{get;}
}

would be the proper way to do it. The problem I see here is your variable
and property naming seems entirely out of standard convention, thus you are
having problems no one else is having.

One other question... why is it okay to suffix EmployeeCollection with
Collection, but it's not okay to prefix EmployeeStatus with an e for enum
and
get eEmployeeStatus (much clearer in my opinion). Isn't a collection a
type
and therefore violating the rule on not revealing type in the variable
name?

Who said putting Collection as a variable or property suffix was acceptable?

 

[Bored Stiff]

Apart from any other considerations, an underscore prefix is not
CLS-compliant