By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,677 Members | 1,237 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,677 IT Pros & Developers. It's quick & easy.

Naming Conventions for Enumerations

P: n/a
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

Nov 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
> What convention do you use when naming an enumeration and variables
that use the enumeration?

Here is a start:
http://msdn.microsoft.com/library/de...guidelines.asp

Furthermore, have a look at :
http://msdn.microsoft.com/library/de...Guidelines.asp

HTH
Erick Sgarbi
www.blog.csharpbox.com
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

Nov 17 '05 #2

P: n/a
or*******@yahoo.com.au wrote:
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
--
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog
Nov 17 '05 #3

P: n/a
Thanks Erick & Oliver

Bill

Nov 17 '05 #4

P: n/a
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

"or*******@yahoo.com.au" wrote:
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

Nov 17 '05 #5

P: n/a

bezel wrote:
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

Nov 17 '05 #6

P: n/a

"Matt" <ma********@sprynet.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

bezel wrote:
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


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.
Nov 17 '05 #7

P: n/a
bezel wrote:
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
--
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog
Nov 17 '05 #8

P: n/a

Daniel O'Connell [C# MVP] wrote:
"Matt" <ma********@sprynet.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

bezel wrote:
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


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

Nov 17 '05 #9

P: n/a


"Matt" wrote:

Daniel O'Connell [C# MVP] wrote:
"Matt" <ma********@sprynet.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

bezel wrote:
> 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


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


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?
Nov 17 '05 #10

P: n/a

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?
Nov 17 '05 #11

P: n/a
Apart from any other considerations, an underscore prefix is not
CLS-compliant

*** Sent via Developersdex http://www.developersdex.com ***
Nov 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.