Member Variables Naming Convention

[Jonathan Wood]

I was just wondering what naming convention most of you use for class
variables.

Underscore, "m_" prefix, camel case, capitalized, etc?

Has one style emerged as the most popular?

Thanks for any comments.

 

[Michael C]

I was just wondering what naming convention most of you use for class
variables.

Underscore, "m_" prefix, camel case, capitalized, etc?

Has one style emerged as the most popular?

I think there are 2 main schools of thought on this. This first is to prefix
it with _. The second is to just make it camel case. I prefer the first
although the second appears to be the MS standard.

Michael

 

[Guest]

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp

I follow these.

Mark.

 

[Tom Shelton]

I was just wondering what naming convention most of you use for class
variables.

Underscore, "m_" prefix, camel case, capitalized, etc?

Has one style emerged as the most popular?

Thanks for any comments.

Camel case.

class TheClass
{
private int theInt;

public int TheInt
{
blah, blah, blah
}
}

 

[Dave Sexton]

Hi,

Just to be clear, I think Michael means lower camel case. Upper camel case
(Pascal case to some) is not acceptable for variable names.

Personally, I think "m_" and "_" are legacy notations and I find them to be
annoying, without any value. I just use lower camel case everywhere.

 

[Kevin Spencer]

I conform *almost* completely to the Microsoft naming conventions, with one
exception: I use an underscore with Pascal case for class member Fields and
Methods that are private or internal, and Pascal case for class member
Fields and Method that are public or protected. This seems to make it easier
to identify the scope of the Field from the Field name, and lessens the
chance that class member Fields which are private or protected will run
into ambiguity issues with parameters. Example:

private float _Cost;
public float Cost { get { return _Cost; } set { _Cost = value; } }

public void Add (float cost)
{
return cost + _Cost;
}

In the above example, the example names are representative of typically
logical names for what they might represent. Occasionally, the situation
occurs when similarly logical names may appear as both a Field and a
parameter in a method. This way, it is easier to identify the difference
inside the Method block.

While I tend to stick closely to Microsoft guidelines for the purpose of
team development ease, I do take a liberty or 2 (and stick to it
consistently) when I think I may have a better idea (which is very seldom).

--
HTH,

Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com

Any experience you can walk away from
is a good one.

 

[Michael Nemtsev]

Hello Jonathan,

Fully support Kevin's point about using "_" that helps to differ private/internal
variables. It is very usefull in codereview, because very often u use simple
text editors for this


JW> I was just wondering what naming convention most of you use for
JW> class variables.
JW>
JW> Underscore, "m_" prefix, camel case, capitalized, etc?
JW>
JW> Has one style emerged as the most popular?
JW>
JW> Thanks for any comments.
JW>
---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Dave Sexton]

Hi Kevin,

You believe that the little value "_" notion provides, if any, outweighs the value of using
standardized naming conventions?

Of course, if you work in an environment where "_" is the accepted standard then it might not be
such a problem, but if you're program is ever touched by anyone else, it might be confusing to them.
Therefore, I don't believe that anyone should take any liberties when there is already
widely-accepted standardization in place.

 

[Michael Nemtsev]

Hello Dave,

What's the most interesting that the widely-accepted standardization is tuned
a little bit to suite company best practice.
I've met the number of cases where "_" was used widely in the big companies
and it gives more pros than cons

DS> Hi Kevin,
DS>
DS> You believe that the little value "_" notion provides, if any,
DS> outweighs the value of using standardized naming conventions?
DS>
DS> Of course, if you work in an environment where "_" is the accepted
DS> standard then it might not be such a problem, but if you're program
DS> is ever touched by anyone else, it might be confusing to them.
DS> Therefore, I don't believe that anyone should take any liberties
DS> when there is already widely-accepted standardization in place.
DS>
DS> DS>---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Registered User]

Hi Kevin,

You believe that the little value "_" notion provides, if any, outweighs the value of using
standardized naming conventions?

Of course, if you work in an environment where "_" is the accepted standard then it might not be
such a problem, but if you're program is ever touched by anyone else, it might be confusing to them.

As long as the convention is used consistently, reasonable cognizant
programmer shouldn't be confused for very long if at all.

Therefore, I don't believe that anyone should take any liberties when there is already
widely-accepted standardization in place.

Agreed, if a convention is already in place it should be followed.
Consistency of use should be the 'real' standard for any naming
convention.

regards
A.G.

 

[Dave Sexton]

Hi Michael,

What's the most interesting that the widely-accepted standardization is tuned a little bit to
suite company best practice.

I think tuning usually occurs because people are used to a certain way of doing things and don't
like to adopt a new standard. The "_" notation is just half-way between "m_" and the standardized,
non-prefix notation (is "_" considered hungarian notation?), so it seems that some people gave in a
little, tuning for comfort but not standards.

I, myself, found that adopting some of the standards for managed programming was annoying at first,
but it was worth it. My code is easier to read now and I have to worry less about other programmers
messing up my code when it flows from organization to organization, given that they too abide by the
standards. In the past, it's always been annoying when my library code was modified and formatting
of the { }, tabs, notation, naming conventions and document structure are completely messed up by
someone doing what they felt was best. Mixing personal preference with standards results in a big
mess.

Of course, in an organization that has internally standardized the "_" notation it's less of a
problem. But new hires must learn the techniques and deployed code may be seen by different
organizations in the future, so its use is not completely isolated.

I've met the number of cases where "_" was used widely in the big companies and it gives more pros
than cons

I acknowledge Kevin's concern with the ambiguity between parameters and fields using the
standardized naming convention, however, I think that qualifying fields looks much better anyway:

public ClassConstructor(int firstNumber, int secondNumber)
{
_FirstNumber = firstNumber;

this.secondNumber = secondNumber;
}

What does "_" provide over the standard, excluding the above?

 

[Dave Sexton]

Hi,

As long as the convention is used consistently, reasonable cognizant
programmer shouldn't be confused for very long if at all.

Why should they have to be confused at all when there is a standard to prevent that in the first
place?

Of course, not all standards are perfect. But I tend to value a standardized approach over
user-choice, because once some liberty is given you can usually expect that a lot more will be
taken.

<snip>

 

[RobinS]

I agree. I always use the underscore to designate
private/internal variables for this reason. It's
a quick visual, rather than having to examine the case.

Robin S.

 

[Jonathan Wood]

Yes, I think camel case always refers to the first letter not being
capitalized.

It appears Microsoft now recommends not using an m_ or _ prefix. The only
thing I don't like about that is you run into problems with arguments having
the same name as member variables (especially in constructors). I personally
don't like using this.var everywhere just to avoid this conflict.

 

[Jonathan Wood]

Thanks for that link.

BTW, these guidelines call for using the same conventions on member
variables as for method arguments. This results in naming conflicts,
especially in constructors.

How do you deal with this issue. (I personally dislike using this.var
everywhere for member variables just to avoid this conflict.)

 

[Jonathan Wood]

Yes, this seems to be the area that I'm now torn between. Microsoft's
guidelines are very specifically against the use of m_ or _. But not only is
it nice to be able to see at a glance if you're looking at a member variable
or something else, it also prevents conflict between argument and member
variables having the same name. In Microsoft Press's C# Step by Step this
issue is dealt with by using this. before all member variables. I just don't
like that or see any need for it.

 

[Registered User]

Hi,



Why should they have to be confused at all when there is a standard to prevent that in the first
place?

What is _the_ industry-wide naming convention standard he asked
rhetorically.

Of course, not all standards are perfect. But I tend to value a standardized approach over
user-choice, because once some liberty is given you can usually expect that a lot more will be
taken.

Since there is no one standard naming convention, every standard is
created by user choice. Naming convention decisions may be made at the
corporate level, department level or even project level. Being able to
understand and work with different naming conventions is an important
part of the skills set. It goes hand-in-hand with being literate in
multiple programming languages.

regards
A.G.

 

[Dave Sexton]

Hi,

No need to ask a rhetorical question because it has already been answered.

I think this link posted by Mark Dawson (in this thread) says it all:

"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp

 

[Dave Sexton]

Hi Jonathan,

Yes, this seems to be the area that I'm now torn between. Microsoft's guidelines are very
specifically against the use of m_ or _. But not only is it nice to be able to see at a glance if
you're looking at a member variable or something else, it also prevents conflict between argument
and member variables having the same name. In Microsoft Press's C# Step by Step this issue is
dealt with by using this. before all member variables. I just don't like that or see any need for
it.

If I had to guess why "_" is not considered standard, for reasons other than those I've already
posted in this thread, I'd say that the designers of these standards saw a need to get rid of
symbols in names. I think the sporadic use of "this" is simply more legible than "_", which only
has meaning when it's assigned by the author. "this", together with lower camel case, is less
likely to be misunderstood.

This is especially useful since .NET development has become an amalgamation of developers from many
different platforms with many different skill-sets and practices. Many developers move to C# and
have to learn a new, unique language with new standards as well. A non-symbolic and expressive
naming convention was in order. I think they made the right choice excluding a random prefix
(seemingly random to people coming from languages where it's not used) from variable names since it
really doesn't provide value anyway.

 

[Guest]

I personally have been through many naming conventions, starting using m_
then moved onto _ and now I prefer to use this. as a prefix. I think the
most important thing is that all developers on a project use the same
standard, you get some people saying "developers should be free to express
themselves" my opinion is that developers can be free to come up with clever
designs and solutions to problems but when they write up those solutions it
should be in a uniform presentation style. There is nothing more frustrating
that moving from one style to another trying to write code which I have found
effects my efficiency when I move to another naming style.

I also believe that using industry standards (i.e. the naming convention
released by Microsoft) is a great way to go, why, because let Microsoft do
all the work of writing the standard docs and publishing them and maintaining
them, while your team can simply reference the docs, new members can easily
refer to the docs and possibly are already using that naming convention since
it is publicly available. Don't waste engineering time on things like this
when you should be spending time developing products.

Mark.
--
http://www.markdawson.org

Hi,

No need to ask a rhetorical question because it has already been answered.

I think this link posted by Mark Dawson (in this thread) says it all:

"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp

--
Dave Sexton

What is _the_ industry-wide naming convention standard he asked
rhetorically.

Since there is no one standard naming convention, every standard is
created by user choice. Naming convention decisions may be made at the
corporate level, department level or even project level. Being able to
understand and work with different naming conventions is an important
part of the skills set. It goes hand-in-hand with being literate in
multiple programming languages.

regards
A.G.