Member Variables Naming Convention

[rossum]

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.

For the most part I use the Microsoft standards, however private
member variables are the one exception; I use the "m_" convention. I
do this because there are three places I can use a variable name: the
member variable itself, the constructor parameter and the property.
The Microsoft standard only allows two versions of the name to cover
the three situations. That is one too few for me.

Example:

class Foo {

private int m_bar; // First use

public Foo(int bar) // Second use

public int Bar { // Third use
get { return m_bar; }
set { m_bar = value; }
}
}

Since both the constructor parameter and the property will be visible
outside the class I use the two Microsoft standards for them, camel
case for the constructor parameter and Pascal case for the property.
The private member variable will not be visible outside the class so
for this one I use the non-Microsoft "m_" naming convention.

rossum

 

[Dave Sexton]

Hi Mark,

Agreed.

--
Dave Sexton

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

On Sat, 18 Nov 2006 12:36:48 -0500, "Dave Sexton"

Hi,

<snip>

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.

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.

 

[Jonathan Wood]

Dave,

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.

Absolutely. I mean, with C++, all strings should be wrapped in the _T()
macro and every run-time library routine and API appears to have both an
ASCII and Unicode version. Clearly, the .NET designers wanted to clean
things up a little and, presumably, thought simple names were cleaner than
all this Hungarian notation, etc.

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.

Yeah, I can't do it. One thing (of many things) that annoy me about .NET is
the verboseness. Having suffered from carpel-tunnel issues from time to
time, I'm not going to prefix every occurrance of a member variable with
five additional characters. I guess that is as good as any argument for me
to adopt the "_" prefix as my personal style.

 

[Jonathan Wood]

Yes, I'm leaning the same way, although I could certain make do with just
the underscore prefix.

 

[Michael Nemtsev]

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

I think tuning occurs to adobt the best code readability

DS> I acknowledge Kevin's concern with the ambiguity between parameters
DS> and fields using the standardized naming convention, however, I
DS> think that qualifying fields looks much better anyway:
DS>
DS> public ClassConstructor(int firstNumber, int secondNumber)
DS> {
DS> _FirstNumber = firstNumber;
DS> this.secondNumber = secondNumber;
DS> }
DS> What does "_" provide over the standard, excluding the above?

that means that "_FirstNumber" is the private/protected property.

It doesn't matter what do u use to differentiate between private/protected
and public, I just take the position that we really need the way to show
the difference. Either _ or m_ or whatever possible.
MS codingstyle suggests nothing for this

---
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

 

[Guest]

Based on the Microsoft guidelines, your code:

class Foo {

private int m_bar; // First use

public Foo(int bar) // Second use

public int Bar { // Third use
get { return m_bar; }
set { m_bar = value; }
}
}

would become:

class Foo {

private int bar; // First use

public Foo(int bar) // Second use
{
this.bar = bar;
}

public int Bar { // Third use
get { return this.bar; }
set { this.bar = value; }
}
}

we could talk all day about which is more readable, however there is no need
to use an m_ notation. I personally prefer the this. to m_ but as I said
this depends on what you are used to, but I think:

1. this.name = name;
2. m_name = name;

1 is cleaner than 2 the names of the variables are not polluted with the m_
prefixes.

Mark.

 

[Dave Sexton]

Hi Jonathon,

Absolutely. I mean, with C++, all strings should be wrapped in the _T() macro and every run-time
library routine and API appears to have both an ASCII and Unicode version. Clearly, the .NET
designers wanted to clean things up a little and, presumably, thought simple names were cleaner
than all this Hungarian notation, etc.

Hungarian notation isn't completely outlawed, however

I see no mention in the standards about the use of "txtFirstName", for example, and I try to use
this notation when I need to distinguish between controls that would otherwise have identical names,
such as, "lblFirstName". Standardized prefixes are desirable, but I can live without them.

Yeah, I can't do it. One thing (of many things) that annoy me about .NET is the verboseness.
Having suffered from carpel-tunnel issues from time to time, I'm not going to prefix every
occurrance of a member variable with five additional characters. I guess that is as good as any
argument for me to adopt the "_" prefix as my personal style.

Not every occurrence of a member variable.

I only use "this" as a prefix once during assignment, usually in a constructor and only if there is
a conflicting parameter name. Other references are without any prefix at all.

 

[Dave Sexton]

Hi Mark,

In the third usage in your example the "this" prefix is unnecessary.


( Don't you just love Saturdays

 

[Guest]

I think the "m_" form for naming fields comes from VB which is not case
sensitive so naming the field something like "lastName" and the associated
property "LastName" just doesn't work.

That said, I agree that it doesn't really fit or add anything in C#.

And underscores are beginning to be recognized as part of a whole new source
of repetitive motion injuries in the workplace associated with little-finger
typing so prefixing with underscores is not a good idea either - nor does it
add any readability to the code.

I like to name all my fields in camel case and my properties in Pascal case.

Dale

 

[Dave Sexton]

Hi Michael,

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

I think tuning occurs to adobt the best code readability

Not always. A lot of programmers are just stubborn. They'll tune away from standardization to
legacy practices so they feel more comfortable, and then try to validate their decision.

DS> I acknowledge Kevin's concern with the ambiguity between parameters
DS> and fields using the standardized naming convention, however, I
DS> think that qualifying fields looks much better anyway:
DS> DS> public ClassConstructor(int firstNumber, int secondNumber)
DS> {
DS> _FirstNumber = firstNumber;
DS> this.secondNumber = secondNumber;
DS> }
DS> What does "_" provide over the standard, excluding the above?

that means that "_FirstNumber" is the private/protected property.

It doesn't matter what do u use to differentiate between private/protected and public, I just take
the position that we really need the way to show the difference. Either _ or m_ or whatever
possible.
MS codingstyle suggests nothing for this

But other than the example above, does an "_" prefix provide any value?

 

[Guest]

I want to repeat my post to another sub-thread of this thread about the
underscore. It is becoming recognized as part of a whole set of characters
that are the source of a new group of repetitive motion injuries in the work
place associated with little-finger typing. For that reason alone, it is
worth not using to me.

Beyond that, I agree with Dave in that I think he's saying what I believe:
we're moving forward in styles and knowledge and application of styles as a
community and, in general, the new ways and standards are the result of
experience and increased understanding.

In otherwords, we know better today than we did before. The new standards
are generally better than the old. Holding on to old habits just because "we
have always done it that way" doesn't make sense.

As a case in point, I often work with developers who have a long history in
main frame development. As an example, a variable that I would call
"serverName", they would argue strongly should be named "srvrnam". Go figure.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

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

 

[Michael Nemtsev]

Hello Dave,
DS> But other than the example above, does an "_" prefix provide any
DS> value?

Maybe not quite undestand u - it provides anything, just mark that we deal
with private/property item.

Any other ideas how to underpin this?

---
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 Nietzsch

 

[Guest]

Using the same convention in constructors works just fine without using
"this". For instance, the compiler understands this perfectly:

public class MyClass
{
int myInt;

public MyClass(int myInt)
{
myInt = myInt;
}
}

The compiler understands it perfectly and assigns to the field myInt, the
value of the parameter myInt. I don't find this confusing either. I know
that if I am assigning like names then that one is going to be the parameter
and one the field.

FxCop, on the other hand, does object to this but what does FxCopy know?

Dale

 

[Hans-J. Ude]

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

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

^^^^^^^^^^
Can someone tell what this expression means? I've never heared that
before. Sounds somewhat funny to me because in german the word camel
stands for something stupid.

TIA
Hans

 

[Dave Sexton]

Hi Dale,

As an example, a variable that I would call
"serverName", they would argue strongly should be named "srvrnam". Go figure.

Nice example.

I think it should be named:

m_strSVRNam1



--
Dave Sexton

I want to repeat my post to another sub-thread of this thread about the
underscore. It is becoming recognized as part of a whole set of characters
that are the source of a new group of repetitive motion injuries in the work
place associated with little-finger typing. For that reason alone, it is
worth not using to me.

Beyond that, I agree with Dave in that I think he's saying what I believe:
we're moving forward in styles and knowledge and application of styles as a
community and, in general, the new ways and standards are the result of
experience and increased understanding.

In otherwords, we know better today than we did before. The new standards
are generally better than the old. Holding on to old habits just because "we
have always done it that way" doesn't make sense.

As a case in point, I often work with developers who have a long history in
main frame development. As an example, a variable that I would call
"serverName", they would argue strongly should be named "srvrnam". Go figure.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

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>

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.
message
Hi Jonathan,

here is a link to the Microsoft guidelines for naming conventions:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpg
enref/html/cpconnamingguidelines.asp

I follow these.

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

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.

---
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

 

[Ben Newsam]

I want to repeat my post to another sub-thread of this thread about the
underscore. It is becoming recognized as part of a whole set of characters
that are the source of a new group of repetitive motion injuries in the work
place associated with little-finger typing. For that reason alone, it is
worth not using to me.

That'sjustplainsilly.OnthatbasisaloneIamgoingtostopusingthespacebarbecauseit'sjusttoomuchtyping.

 

[Jonathan Wood]

I don't like this approach but I do think that if you adopt the
this.membervar syntax, you should use it consistently. If the "this." prefix
is the only thing preventing possible confusion between args and member
variables, then you need to get into the habit of using it everywhere.
Otherwise, the most likely of typing mistakes could produce significant
bugs.

This is the approach taken in the latest C# Step by Step book as well.

 

[Ben Newsam]

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.

Which makes it a bit odd that those of us used to "m_" prefixes and
Hungarian notation as wellshould be expected to reduce to no
conventions at all in this respect.

 

[Jonathan Wood]

Dave,

Hungarian notation isn't completely outlawed, however

Actually, in the Microsoft guidelines, it really is.

I see no mention in the standards about the use of "txtFirstName", for
example, and I try to use this notation when I need to distinguish between
controls that would otherwise have identical names, such as,
"lblFirstName". Standardized prefixes are desirable, but I can live
without them.

Reference to controls is a bit different that straight variables. I haven't
see what the guidelines say about that.

Not every occurrence of a member variable.

I think consistency is important. Using the this. prefix only some of the
time could get you into trouble.

 

[Jonathan Wood]

Dale,

I think the "m_" form for naming fields comes from VB which is not case
sensitive so naming the field something like "lastName" and the associated
property "LastName" just doesn't work.

The "m_" prefix was standardized in C++/MFC. Microsoft consistently used
that throughout MFC and I've certainly used the same standard in VB code. (I
used to write a regular column in Visual Basic Programmer's Journal.) And it
should be noted that C++ is definitely case-sensitive.

And underscores are beginning to be recognized as part of a whole new
source
of repetitive motion injuries in the workplace associated with
little-finger
typing so prefixing with underscores is not a good idea either - nor does
it
add any readability to the code.

As has been pointed out, you kind of need a "_" prefix or use this. before
each member variable. I would argue that five characters is harder on the
carpel tunnel than one is.