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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Michael C]

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>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

[Mark R. Dawson]

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Tom Shelton]

Jonathan Wood wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Camel case.

class TheClass
{
private int theInt;

public int TheInt
{
blah, blah, blah
}
}

--
Tom Shelton

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

--
Dave Sexton

"Michael C" <no****@nospam.comwrote in message
news:uY**************@TK2MSFTNGP02.phx.gbl...

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

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

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

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microsof t.com...

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[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
JWI was just wondering what naming convention most of you use for
JWclass variables.
JW>
JWUnderscore, "m_" prefix, camel case, capitalized, etc?
JW>
JWHas one style emerged as the most popular?
JW>
JWThanks 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.

--
Dave Sexton

"Kevin Spencer" <sp**@uce.govwrote in message news:Om*************@TK2MSFTNGP06.phx.gbl...

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

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microsof t.com...

>Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[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

DSHi Kevin,
DS>
DSYou believe that the little value "_" notion provides, if any,
DSoutweighs the value of using standardized naming conventions?
DS>
DSOf course, if you work in an environment where "_" is the accepted
DSstandard then it might not be such a problem, but if you're program
DSis ever touched by anyone else, it might be confusing to them.
DSTherefore, I don't believe that anyone should take any liberties
DSwhen there is already widely-accepted standardization in place.
DS>
DS"Kevin Spencer" <sp**@uce.govwrote in message
DSnews:Om*************@TK2MSFTNGP06.phx.gbl...
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.
"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in
message news:1D**********************************@microsof t.com...

>>Hi Jonathan,

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

http://msdn.microsoft.com/library/de...rary/en-us/cpg
enref/html/cpconnamingguidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

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

On Sat, 18 Nov 2006 09:55:38 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

>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

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

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>

--
Dave Sexton

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

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...

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
JWI was just wondering what naming convention most of you use for
JWclass variables.
JWJWUnderscore, "m_" prefix, camel case, capitalized, etc?
JWJWHas one style emerged as the most popular?
JWJWThanks 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

[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
SoftCircuits Programming
http://www.softcircuits.com

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:Ot**************@TK2MSFTNGP06.phx.gbl...

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.

--
Dave Sexton

"Michael C" <no****@nospam.comwrote in message
news:uY**************@TK2MSFTNGP02.phx.gbl...

>"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

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

[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
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microsof t.com...

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...

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
JWI was just wondering what naming convention most of you use for
JWclass variables.
JWJWUnderscore, "m_" prefix, camel case, capitalized, etc?
JWJWHas one style emerged as the most popular?
JWJWThanks 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

[Registered User]

On Sat, 18 Nov 2006 12:36:48 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

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

[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/de...guidelines.asp

--
Dave Sexton

"Registered User" <n4***@ix.netcom.comwrote in message
news:nu********************************@4ax.com...

On Sat, 18 Nov 2006 12:36:48 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

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

[Dave Sexton]

Hi Jonathan,

<snip>

>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

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.

--
Dave Sexton

[Mark R. Dawson]

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
"Dave Sexton" wrote:

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/de...guidelines.asp

--
Dave Sexton

"Registered User" <n4***@ix.netcom.comwrote in message
news:nu********************************@4ax.com...

On Sat, 18 Nov 2006 12:36:48 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

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

[rossum]

On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

>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

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:AC**********************************@microsof t.com...

>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
"Dave Sexton" wrote:

>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/de...guidelines.asp

--
Dave Sexton

"Registered User" <n4***@ix.netcom.comwrote in message
news:nu********************************@4ax.com.. .

On Sat, 18 Nov 2006 12:36:48 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

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
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"rossum" <ro******@coldmail.comwrote in message
news:kh********************************@4ax.com...

On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

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

[Mark R. Dawson]

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.
--
http://www.markdawson.org
"rossum" wrote:

On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

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

[Michael Nemtsev]

Hello Dave,

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

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

I think tuning occurs to adobt the best code readability

DSI acknowledge Kevin's concern with the ambiguity between parameters
DSand fields using the standardized naming convention, however, I
DSthink that qualifying fields looks much better anyway:
DS>
DSpublic ClassConstructor(int firstNumber, int secondNumber)
DS{
DS_FirstNumber = firstNumber;
DSthis.secondNumber = secondNumber;
DS}
DSWhat 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

[Dave Sexton]

Hi Jonathon,

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

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.

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

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

[Dave Sexton]

Hi Mark,

In the third usage in your example the "this" prefix is unnecessary.
( Don't you just love Saturdays ;)

--
Dave Sexton

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:39**********************************@microsof t.com...

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.
--
http://www.markdawson.org
"rossum" wrote:

>On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

>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

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

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

--
Dale Preston
MCAD C#
MCSE, MCDBA
"Dave Sexton" wrote:

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.

--
Dave Sexton

"Michael C" <no****@nospam.comwrote in message
news:uY**************@TK2MSFTNGP02.phx.gbl...

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>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

[Dave Sexton]

Hi Michael,

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

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.

DSI acknowledge Kevin's concern with the ambiguity between parameters
DSand fields using the standardized naming convention, however, I
DSthink that qualifying fields looks much better anyway:
DSDSpublic ClassConstructor(int firstNumber, int secondNumber)
DS{
DS_FirstNumber = firstNumber;
DSthis.secondNumber = secondNumber;
DS}
DSWhat 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?

--
Dave Sexton

[Dale]

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
"Michael Nemtsev" wrote:

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

DSHi Kevin,
DS>
DSYou believe that the little value "_" notion provides, if any,
DSoutweighs the value of using standardized naming conventions?
DS>
DSOf course, if you work in an environment where "_" is the accepted
DSstandard then it might not be such a problem, but if you're program
DSis ever touched by anyone else, it might be confusing to them.
DSTherefore, I don't believe that anyone should take any liberties
DSwhen there is already widely-accepted standardization in place.
DS>
DS"Kevin Spencer" <sp**@uce.govwrote in message
DSnews:Om*************@TK2MSFTNGP06.phx.gbl...
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.
"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in
message news:1D**********************************@microsof t.com...

Hi Jonathan,

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

http://msdn.microsoft.com/library/de...rary/en-us/cpg
enref/html/cpconnamingguidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

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

[Dale]

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
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Jonathan Wood" wrote:

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
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microsof t.com...

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Hans-J. Ude]

"Jonathan Wood" <jw***@softcircuits.comwrote:

>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

[Michael Nemtsev]

Hello Dave,

>DSDSpublic ClassConstructor(int firstNumber, int secondNumber)
DS{
DS_FirstNumber = firstNumber;
DSthis.secondNumber = secondNumber;
DS}
DSWhat 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

DSBut other than the example above, does an "_" prefix provide any
DSvalue?

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 Nietzsche

[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

"Dale" <da******@nospam.nospamwrote in message
news:7E**********************************@microsof t.com...

>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
"Michael Nemtsev" wrote:

>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

DSHi Kevin,
DS>
DSYou believe that the little value "_" notion provides, if any,
DSoutweighs the value of using standardized naming conventions?
DS>
DSOf course, if you work in an environment where "_" is the accepted
DSstandard then it might not be such a problem, but if you're program
DSis ever touched by anyone else, it might be confusing to them.
DSTherefore, I don't believe that anyone should take any liberties
DSwhen there is already widely-accepted standardization in place.
DS>
DS"Kevin Spencer" <sp**@uce.govwrote in message
DSnews:Om*************@TK2MSFTNGP06.phx.gbl...
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.
"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in
message news:1D**********************************@microsof t.com...

Hi Jonathan,

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

http://msdn.microsoft.com/library/de...rary/en-us/cpg
enref/html/cpconnamingguidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

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

On Sat, 18 Nov 2006 13:54:02 -0800, Dale <da******@nospam.nospam>
wrote:

>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.OnthatbasisaloneIamgoingtosto pusingthespacebarbecauseit'sjusttoomuchtyping.

--
Posted via a free Usenet account from http://www.teranews.com

[Ben Newsam]

On Sat, 18 Nov 2006 14:56:08 -0500, Registered User
<n4***@ix.netcom.comwrote:

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

--
Posted via a free Usenet account from http://www.teranews.com

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...

Hi Mark,

In the third usage in your example the "this" prefix is unnecessary.
( Don't you just love Saturdays ;)

--
Dave Sexton

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:39**********************************@microsof t.com...

>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.
--
http://www.markdawson.org
"rossum" wrote:

>>On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

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

[Jonathan Wood]

Dave,

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

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.

>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 think consistency is important. Using the this. prefix only some of the
time could get you into trouble.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Hans-J. Ude" <ne**@hajue-ude.dewrote in message
news:qj********************************@4ax.com...

"Jonathan Wood" <jw***@softcircuits.comwrote:

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

[Jonathan Wood]

Ack! I don't like that at all. What about myInt = myInt + myInt? I mean,
I've never *ever* seen anyone do this. I'll just have to take your word for
it that it actual works (it doesn't seem like it could). But I would avoid
this approach like the plague.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Dale" <da******@nospam.nospamwrote in message
news:0C**********************************@microsof t.com...

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
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Jonathan Wood" wrote:

>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
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microso ft.com...

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp

I follow these.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Mark R. Dawson]

Hi Dave,
I would say it is "not essential" rather than "not necessary", indeed the
code will work without the this. prefix in the third case but I consistently
use "this." to access all of my class fields throught my code so that I can
distinguish between local variables and class fields easily :-)

Mark.
--
http://www.markdawson.org
"Dave Sexton" wrote:

Hi Mark,

In the third usage in your example the "this" prefix is unnecessary.
( Don't you just love Saturdays ;)

--
Dave Sexton

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:39**********************************@microsof t.com...

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.
--
http://www.markdawson.org
"rossum" wrote:

On Fri, 17 Nov 2006 16:27:51 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

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

[Mark R. Dawson]

There are different flavours of camel casing too, most commenly camel case
refers to lower camel case i.e. thisIsLowerCamelCase, however there is also
upper camel case ThisIsUpperCamelCase which is also referred to as Pascal
case.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Hans-J. Ude" <ne**@hajue-ude.dewrote in message
news:qj********************************@4ax.com...

"Jonathan Wood" <jw***@softcircuits.comwrote:

>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

[Jonathan Wood]

I have only seen the second example referred to as Pascal case. I've yet to
read anyone who used the term camel case to describe that convention.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:AE**********************************@microsof t.com...

There are different flavours of camel casing too, most commenly camel case
refers to lower camel case i.e. thisIsLowerCamelCase, however there is
also
upper camel case ThisIsUpperCamelCase which is also referred to as Pascal
case.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

>Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Hans-J. Ude" <ne**@hajue-ude.dewrote in message
news:qj********************************@4ax.com.. .

"Jonathan Wood" <jw***@softcircuits.comwrote:

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

[Mark R. Dawson]

I don't believe it is very common usage, one of the professors at my uni
used to use that term, but apart from him not heard anyone else use it and
seems like wikipedia also has comments on this (believe it as you will :-)):

http://en.wikipedia.org/wiki/Camel_case

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

I have only seen the second example referred to as Pascal case. I've yet to
read anyone who used the term camel case to describe that convention.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:AE**********************************@microsof t.com...

There are different flavours of camel casing too, most commenly camel case
refers to lower camel case i.e. thisIsLowerCamelCase, however there is
also
upper camel case ThisIsUpperCamelCase which is also referred to as Pascal
case.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Hans-J. Ude" <ne**@hajue-ude.dewrote in message
news:qj********************************@4ax.com...
"Jonathan Wood" <jw***@softcircuits.comwrote:

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

[Hans-J. Ude]

"Jonathan Wood" <jw***@softcircuits.comschrieb:

>Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

Thanks for the info everbody. I'm new to C# and as an old MFC
programmer I'm very accustomed to the "m_" and "CMyClass" convention.
I begin liking C# and consider to learn it better. Since I'm at the
beginning right now I don't want to "learn" any mistakes which are
hard to get rid of later. In another post in this thread Jonathan
writes "It appears Microsoft now recommends not using an m_ or _
prefix." I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me. When I take a look at the
ScreenSaver and MovieCollection samples I see they are usig that
"camel case" convention. I must admit that I find it ugly, but that's
probably because i'm not used to read and write it.

Hans

--
There are 10 kinds of people. Those who understand binary and those who
don't. <unknown source>

[Mark R. Dawson]

The compiler understands it perfectly and assigns to the field myInt, the

value of the parameter myInt.

Not true, if you have:

class Person
{
private string name;

public Person(string name)
{
name = name;
}
}

Then the compiler will simply assign the local variable name to itself, you
will get a warning about this (hopefully an error since nobody would leave
the "treat warning as error" option unchecked :-P), after the constructor has
executed the class field "name" is still null.

This is also very confusing, the "this." is required. Also in the case below:

class Person
{
private string name;

public Person(string name)
{
name = name;
}

public void DoSomething(string name)
{
string finalName = name + "xyz";
}
}

The compiler does not give any warning about the possible ambiguity of the
variable named "name", did you mean to use the local variable or the class
field but forgot the this. prefix, from what I can tell this is possibly a
case against using the this. notation.

Mark.
--
http://www.markdawson.org
"Dale" wrote:

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
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Jonathan Wood" wrote:

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
SoftCircuits Programming
http://www.softcircuits.com

"Mark R. Dawson" <Ma*********@discussions.microsoft.comwrote in message
news:1D**********************************@microsof t.com...

Hi Jonathan,
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...guidelines.asp
>
I follow these.
>
Mark.
--
http://www.markdawson.org
>
>
"Jonathan Wood" wrote:
>
>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.
>>
>--
>Jonathan Wood
>SoftCircuits Programming
>http://www.softcircuits.com
>>
>>
>>

[Jonathan Wood]

Mark,

>The compiler understands it perfectly and assigns to the field myInt, the
value of the parameter myInt.

Not true, if you have:

class Person
{
private string name;

public Person(string name)
{
name = name;
}
}

Then the compiler will simply assign the local variable name to itself,
you
will get a warning about this (hopefully an error since nobody would leave
the "treat warning as error" option unchecked :-P), after the constructor
has
executed the class field "name" is still null.

You know, I would've sworn that was the case. But since I have no tested it
directlyed, I was not comfortable saying Dale was wrong. I figured he tried
it out.

As far as I'm concerned, this should not work and should be avoided even if
it did work.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Mark R. Dawson]

Hi Jonathan,
I agree, I am not sure why self assignment is legal, maybe there is some
perfectly good case for it, I can't think of any though.

Mark.
--
http://www.markdawson.org
"Jonathan Wood" wrote:

Mark,

The compiler understands it perfectly and assigns to the field myInt, the
value of the parameter myInt.

Not true, if you have:

class Person
{
private string name;

public Person(string name)
{
name = name;
}
}

Then the compiler will simply assign the local variable name to itself,
you
will get a warning about this (hopefully an error since nobody would leave
the "treat warning as error" option unchecked :-P), after the constructor
has
executed the class field "name" is still null.

You know, I would've sworn that was the case. But since I have no tested it
directlyed, I was not comfortable saying Dale was wrong. I figured he tried
it out.

As far as I'm concerned, this should not work and should be avoided even if
it did work.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com