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

[Dave Sexton]

Hi Michael,

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

Any other ideas how to underpin this?

Well, "_" doesn't seem to provide any value that doesn't exist using the standard notation. If I
see something like, "firstNumber" in a method body it's usually obvious to me whether its a field or
a parameter just by quickly scanning the method, considering that the method was properly designed
to be succinct, or even just by context and its chosen name. In larger methods a simple mouse-over
does the trick. Intellisense tells us when a variable is a "local variable" (although I rarely even
need that information from intellisense, if ever). Otherwise, when "(local variable)" isn't
displayed, it's a field. And, if an object is confusing to the point where something such as
"firstNumber" isn't obviously a field or a local variable, then the chosen name might not be
descriptive enough.

So the best argument for "_" so far is that it alleviates parameter ambiguity without requiring
"this.", which I actually prefer over "_" anyway. Furthermore, "this." has been standardized while
"_" is not recommended by Microsoft.

--
Dave Sexton

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

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

>Hungarian notation isn't completely outlawed, however :)

Actually, in the Microsoft guidelines, it really is.

No, it's really not :)

Care to show me where Microsoft says that controls shouldn't be named with prefixes such as "txt" or
"lbl"?

(They are stored as private fields, you know)

--
Dave Sexton

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:OR**************@TK2MSFTNGP04.phx.gbl...

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

[Dave Sexton]

Hi Mark,

I don't and I've never had a problem. I use "this." when it's required by the compiler to qualify a
reference, otherwise I just reference the field directly.

I have nothing against "this." since it can only makes things clearer when present, but I opt for
less typing :)

--
Dave Sexton

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

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**********************************@microso ft.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]

Well I was going to look that up again but I see you gave me a trick
question. I just stated in the post you were replying to that I considered
references to controls a bit different than straight variables. Perhaps you
didn't read my entire post, eh? We were talking about member variables.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O5**************@TK2MSFTNGP04.phx.gbl...

Hi Jonathan,

>>Hungarian notation isn't completely outlawed, however :)

Actually, in the Microsoft guidelines, it really is.

No, it's really not :)

Care to show me where Microsoft says that controls shouldn't be named with
prefixes such as "txt" or "lbl"?

(They are stored as private fields, you know)

--
Dave Sexton

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:OR**************@TK2MSFTNGP04.phx.gbl...

>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

[Dave Sexton]

Hi Hans,

<snip>

I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me

Following standards provides real value through consistency. Not following any standards makes
development harder by creating friction when moving amongst different notations and conventions.
Making up your own standards makes interoperability harder, inevitably making development harder as
well - even if its not harder for you it will be for someone else one day that has to work with your
atypical code.

<snip>

I must admit that I find it ugly, but that's
probably because i'm not used to read and write it.

Yes, it is ugly if you're used to something else. I think the ugliness factor is the number one
reason for introducing legacy standards into modern, standardized code, although it definitely isn't
the only reason.

--
Dave Sexton

[Dave Sexton]

Hi Jonathan,

Well I was going to look that up again but I see you gave me a trick question. I just stated in
the post you were replying to that I considered references to controls a bit different than
straight variables. Perhaps you didn't read my entire post, eh? We were talking about member
variables.

I read your entire post. No tricks here :)

We are talking about fields (member variables, as you say), which txtFirstName and lblFirstName
certainly are.

How would you name these two Controls?

--
Dave Sexton

[Jonathan Wood]

Dave,

>Well I was going to look that up again but I see you gave me a trick
question. I just stated in the post you were replying to that I
considered references to controls a bit different than straight
variables. Perhaps you didn't read my entire post, eh? We were talking
about member variables.

I read your entire post. No tricks here :)

We are talking about fields (member variables, as you say), which
txtFirstName and lblFirstName certainly are.

How would you name these two Controls?

Well, as I indicated, I consider that a different issue. I haven't decided
on this issue for sure, but I have a tendancy to stick with what I did in
VB, which is to include those prefixes.

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

[Dave Sexton]

Hi Jonathan,

>>Well I was going to look that up again but I see you gave me a trick question. I just stated in
the post you were replying to that I considered references to controls a bit different than
straight variables. Perhaps you didn't read my entire post, eh? We were talking about member
variables.

I read your entire post. No tricks here :)

We are talking about fields (member variables, as you say), which txtFirstName and lblFirstName
certainly are.

How would you name these two Controls?

Well, as I indicated, I consider that a different issue. I haven't decided on this issue for sure,
but I have a tendancy to stick with what I did in VB, which is to include those prefixes.

I don't see it as a different issue at all. They are fields. (but the point is a moot one anyway
since you were right...)

BTW, I found two interesting bullets in a Microsoft document [link below] regarding the use of
hungarian notation and the "_" prefix in field names:

- Do not use Hungarian notation for field names. Good names describe semantics, not type.

I must argue here that my examples of txtFirstName and lblFirstName indicate both type and
semantics. However, I use the notation in other controls even when there is no ambiguity, but I'm
going to try to break that habit for my next project. Do I really need to know that a field is a
Control by looking at its name when I have intellisense and tooltips on hand at all times? - I
don't think so, but I'll see how it goes ;)

- Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to
a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_
prefix is incorrect.

"Field Usage Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...asp?frame=true

--
Dave Sexton

[Jonathan Wood]

Dave,

BTW, I found two interesting bullets in a Microsoft document [link below]
regarding the use of hungarian notation and the "_" prefix in field names:

Yeah, those were the ones I was thinking about. Microsoft is being very
one-sided about not using those prefixes. If you see where they talk about
control names, please pass it along.

I must argue here that my examples of txtFirstName and lblFirstName
indicate both type and semantics. However, I use the notation in other
controls even when there is no ambiguity, but I'm going to try to break
that habit for my next project. Do I really need to know that a field is
a Control by looking at its name when I have intellisense and tooltips on
hand at all times? - I don't think so, but I'll see how it goes ;)

I think it is still useful. Yes, Intellisense offers assistance here but I
often print code and review it in more detail. Also, for more complex code,
it may just be more efficient to know what a variable refers to just by
looking.

In the end, I have mixed feelings about this. I'm all for cleaning things
up, but I've been programming a long, long time and readability is
important. I'm not 100% sure I'm ready to abandon prefixes that tell me
about a particular variable.

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

[Cor Ligthert [MVP]]

Jonathan,

I just find that underscore hard to read in some situation.

While it is in my idea not on the most nice place on the keyboard for those
who are using 10 fingers to type.

Very good to create RSI.

Cor

"Jonathan Wood" <jw***@softcircuits.comschreef in bericht
news:us**************@TK2MSFTNGP02.phx.gbl...

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

[Cor Ligthert [MVP]]

Hans,

At a certain moment you will see that you are using it by accident in normal
letters. Sometimes it is even then very handy to use.

:-)

Cor
"Hans-J. Ude" <ne**@hajue-ude.deschreef in bericht
news:f3********************************@4ax.com...

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

[Michael Nemtsev]

Hello Dave,

DSHi Michael,
DS>

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

Any other ideas how to underpin this?

DSWell, "_" doesn't seem to provide any value that doesn't exist using
DSthe standard notation. If I see something like, "firstNumber" in a
DSmethod body it's usually obvious to me whether its a field or a
DSparameter just by quickly scanning the method, considering that the
DSmethod was properly designed to be succinct, or even just by context
DSand its chosen name.

Right

DSIn larger methods a simple mouse-over does the
DStrick. Intellisense tells us when a variable is a "local variable"
DS(although I rarely even need that information from intellisense, if
DSever). Otherwise, when "(local variable)" isn't displayed, it's a
DSfield.

Ok, now u was asked to review the code. You got 2 version of source files
from CVS, open them in diff editor and starting review changes. There is
no intellisence. An catch that difference u described above is really hard

DSAnd, if an object is confusing to the point where something
DSsuch as "firstNumber" isn't obviously a field or a local variable,
DSthen the chosen name might not be descriptive enough.

What do u suggest for naming convention to distinguish locals/fields?
We are not in the perfect world where is the each method is on the screen's
lenght.

it's a little bit simple if we use encapsulation, where no direct access
to fieds, only properties - camel case for private and pascal for public
fields. but we are again stumble over ambiguity between the local variable
and the private property
DSSo the best argument for "_" so far is that it alleviates parameter
DSambiguity without requiring "this.", which I actually prefer over
DS"_" anyway. Furthermore, "this." has been standardized while "_" is
DSnot recommended by Microsoft.

I don't like "_" too, but it seems to be the simplest and neat solution


DS>
DS"Michael Nemtsev" <ne*****@msn.comwrote in message
DSnews:17***************************@msnews.micros oft.com...
DS>

>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

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

[Bruce Wood]

Dave Sexton wrote:

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

I hated the idea when a coworker introduced it, but now I'm all for it.
We're gradually converting our code over to using the "_" prefix for
member variables. Here's why.

Keep in mind that most of us are no longer writing code in text editors
and peering at printouts. Most of us are using Visual Studio and
Intellisense. I think that Hungarian Notation was a good idea for
assembly language, but it should have a stake driven through its heart
these days because if I want to know what type something is, I mouse
over it and VS tells me. So, there are now TWO considerations: the
written code itself, and the code within the Visual Studio environment.

With this in mind, we had an annoying problem when we followed what
appear to be MS's official guildelines. Given code like this:

public class Blah
{
private int foo;

public int Foo { get { return this.foo; } set { this.foo = value; }
}
}

and remembering that Intellisense is case-INsensitive, one can
immediately see why Intellisense has the annoying habit of choosing one
of this.foo or this.Foo "at random" when I type "this.f" from inside
the Blah class scope. This led to not a few bugs in our code, as touch
typists like me who often type without watching the screen would end up
with references to the property instead of to the member variable. I
lost count of how many infinite loops I introduced that way.

The "_" introduced two improvements. First, it's unambiguous when typed
in VS: "this._f" always means you want a member variable starting with
f, whereas "this.f" or "this.F" always indicates something public,
probably a property or method.

Second, all member variables appear at the top of the list in the
debugger, so you don't have to go hunting for them.

Does it make the code or less readable on printout? Doesn't much matter
to me. It does, however, make VS easier to use, and since that's where
I spend most of my coding and debugging time, that matters a lot.

[Michael C]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message

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.

I can't argue with you on _ being annoying, that is a matter of taste but I
think the statement that it is without any value isn't true. The value is of
course that it shows what is a member variable and it allows properties to
have the same name as the variable. It also avoids the problem of using only
case to distinguish 2 different items, something which I prefer to avoid. It
also makes it easy to find all member vars in intellisense (something that
prefixing with m never did). I can understand disputing the usefulness of
this "value" but I don't think you can argue that no value exists.

Michael

[Registered User]

On Sat, 18 Nov 2006 15:22:18 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

>
I think consistency is important.

You're dead on target. Regardless of the naming convention used in a
project, consistency is the crux of the biscuit. If the convention
isn't followed it is of no value.

The OP wrote of programmers being confused by different naming
conventions. The responses indicate a great deal of personal
preference but no tales of confusion have been told.

regards
A.G.

[Registered User]

On Sun, 19 Nov 2006 07:19:56 -0500, Registered User
<n4***@ix.netcom.comwrote:

>On Sat, 18 Nov 2006 15:22:18 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

>>
I think consistency is important.

You're dead on target. Regardless of the naming convention used in a
project, consistency is the crux of the biscuit. If the convention
isn't followed it is of no value.

I got this wrong. It wasn't the OP but a followup that mentioned
confusion.

>The OP wrote of programmers being confused by different naming
conventions. The responses indicate a great deal of personal
preference but no tales of confusion have been told.

regards
A.G.

[Mattias Sjögren]

Dave,

>"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...guidelines.asp

These guidelines are primarily for publicly accessible members.

"The goal of the .NET Framework design guidelines is to encourage
consistency and predictability in *public APIs* while enabling Web and
cross-language integration." (Emphasis added)

http://msdn.microsoft.com/library/de...guidelines.asp

And more clearly

"Casing and naming guidelines apply only to public and protected
identifiers, and privately implemented interface members. Teams are
free to choose their own guidelines for internal and private
identifiers."

http://blogs.msdn.com/kcwalina/archi...28/235232.aspx
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Dave Sexton]

Hi Michael,

I can't argue with you on _ being annoying, that is a matter of taste but I think the statement
that it is without any value isn't true. The value is of course that it shows what is a member
variable and it allows properties to have the same name as the variable. It also avoids the
problem of using only case to distinguish 2 different items, something which I prefer to avoid. It
also makes it easy to find all member vars in intellisense (something that prefixing with m never
did). I can understand disputing the usefulness of this "value" but I don't think you can argue
that no value exists.

I wasn't questioning its use, I was questioning its value.

And I can argue that no value exists - I did in another post :)

--
Dave Sexton

[Dave Sexton]

Hi Michael,

<snip>

DSIn larger methods a simple mouse-over does the
DStrick. Intellisense tells us when a variable is a "local variable"
DS(although I rarely even need that information from intellisense, if
DSever). Otherwise, when "(local variable)" isn't displayed, it's a
DSfield.
Ok, now u was asked to review the code. You got 2 version of source files from CVS, open them in
diff editor and starting review changes. There is no intellisence. An catch that difference u
described above is really hard

Ok, you're definitely correct that intellisense and tooltips aren't always available :)

But if the method's purpose is known and variable names are meaningful, I don't see how that could
be a problem. It's never been a real problem for me, at least not enough to warrant the use of an
"_" before all fields in my entire system and to go against a standard.

DSAnd, if an object is confusing to the point where something
DSsuch as "firstNumber" isn't obviously a field or a local variable,
DSthen the chosen name might not be descriptive enough.

What do u suggest for naming convention to distinguish locals/fields?
We are not in the perfect world where is the each method is on the screen's lenght.

In VS, context should be enough, or use descriptive names, or it shouldn't matter:

class Color
{
byte r, g, b;

public void ConvolutedRandomization(int factor)
{
// It doesn't matter whether "rnd" is a field or local variable, later in code.
// The instance will be used regardless of its origin.
Random rnd = new Random();

// It doesn't matter, later in code, whether randomR is a field or a local.
// The only thing we'll care about when its required is its value.
byte randomR = (byte) rnd.Next(0, Math.Min(256, factor))
byte randomG = (byte) rnd.Next(0, Math.Min(256, factor))
byte randomB = (byte) rnd.Next(0, Math.Min(256, factor))

// we know we're assigning to fields because that's the purpose
// of this method.
r = Math.Min(256, r * randomR);
g = Math.Min(256, g * randomG);
b = Math.Min(256, b * randomB);
}
}
class Color
{
byte _r, _g, _b;

public void ConvolutedRandomization(int factor)
{
Random rnd = new Random();

byte randomR = (byte) rnd.Next(0, Math.Min(256, factor))
byte randomG = (byte) rnd.Next(0, Math.Min(256, factor))
byte randomB = (byte) rnd.Next(0, Math.Min(256, factor))

_r = Math.Min(256, _r * randomR);
_g = Math.Min(256, _g * randomG);
_b = Math.Min(256, _b * randomB);
}
}

You might feel that it's much clearer in the latter version whether "_r" is a local or a field, but
does that provide any value? After all, if you understand the method then it should be obvious, and
anyway there really is no ambiguity here. Why even assume that "r", in the first example, is a
local variable?

it's a little bit simple if we use encapsulation, where no direct access to fieds, only
properties - camel case for private and pascal for public fields. but we are again stumble over
ambiguity between the local variable and the private property

Outside of VS, as you pointed out, it may be a problem. Definitely not inside, however.

<snip>

--
Dave Sexton

[Dave Sexton]

Hi Bruce,

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

I hated the idea when a coworker introduced it, but now I'm all for it.
We're gradually converting our code over to using the "_" prefix for
member variables. Here's why.

Keep in mind that most of us are no longer writing code in text editors
and peering at printouts. Most of us are using Visual Studio and
Intellisense. I think that Hungarian Notation was a good idea for
assembly language, but it should have a stake driven through its heart
these days because if I want to know what type something is, I mouse
over it and VS tells me. So, there are now TWO considerations: the
written code itself, and the code within the Visual Studio environment.

With this in mind, we had an annoying problem when we followed what
appear to be MS's official guildelines. Given code like this:

public class Blah
{
private int foo;

public int Foo { get { return this.foo; } set { this.foo = value; }
}
}

and remembering that Intellisense is case-INsensitive, one can
immediately see why Intellisense has the annoying habit of choosing one
of this.foo or this.Foo "at random" when I type "this.f" from inside
the Blah class scope. This led to not a few bugs in our code, as touch
typists like me who often type without watching the screen would end up
with references to the property instead of to the member variable. I
lost count of how many infinite loops I introduced that way.

But I've already stated that I never use "this." unless I must resolve an ambiguity issue for the
compiler. It's pointless there, and you've also proven that it may be dangerous as well.

The "_" introduced two improvements. First, it's unambiguous when typed
in VS: "this._f" always means you want a member variable starting with
f, whereas "this.f" or "this.F" always indicates something public,
probably a property or method.

That's a good point if you're using "this." everywhere, which I know a lot of programmers do. I
don't because it's more typing and provides no real value, IMO.

Second, all member variables appear at the top of the list in the
debugger, so you don't have to go hunting for them.

Good, descriptive names and code layout alleviate the need to search for members based on their
member type in a large intellisense list.

Normally, just typing "f Ctrl+Space" is enough to find "foo", otherwise it probably shouldn't be
named "foo" in the first place. And even if it's unavoidable that "foo" will be difficult to find
using intellisense due to an overwhelming number of fields in a class, or other complexities, you
could also code like I do and group all private fields together. I've posted my layout snippets
after my sig.

Does it make the code or less readable on printout? Doesn't much matter
to me. It does, however, make VS easier to use, and since that's where
I spend most of my coding and debugging time, that matters a lot.

I agree that VS is more important than outside of VS since that's where the large majority of my
time is spent as well.

--
Dave Sexton
All of my structs and classes (components and non-components) use the following layout, so it's very
easy to locate the names of fields. As a matter of fact, I often have the Private / Protected
region expanded when I'm coding methods so I don't have to browse through a long list of fields in a
complex object. I'm sure that helps me locate unknown field names much faster than browsing a list
of members that all begin with "_".

(Watch for tabbing issues if anyone tries to use the snippets since I pasted them here and the
formatting was probably lost)

{ layout.snippet }

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>layout</Title>
<Shortcut>layout</Shortcut>
<Description>Code snippet for region layout of code files</Description>
<Author>Dave Sexton</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal Editable="false">
<ID>class</ID>
<Function>ClassName()</Function>
</Literal>
</Declarations>
<Code Language="csharp">
<![CDATA[#region Public Properties
#endregion

#region Private / Protected
#endregion

#region Constructors
/// <summary>
/// Constructs a new instance of the <see cref="$class$" /class.
/// </summary>
public $class$($end$)
{
}
#endregion

#region Methods
#endregion

#region Events
#endregion

#region Event Handlers
#endregion

#region Nested
#endregion]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

{ layoutc.snippet }

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>layoutc</Title>
<Shortcut>layoutc</Shortcut>
<Description>Code snippet for region layout of code files that contain a class that can be edited
in a designer (derived from Component)</Description>
<Author>Dave Sexton</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal Editable="false">
<ID>class</ID>
<Function>ClassName()</Function>
</Literal>
</Declarations>
<Code Language="csharp">
<![CDATA[#region Public Properties
#endregion

#region Private / Protected
$end$
#endregion

#region Constructors
/// <summary>
/// Constructs a new instance of the <see cref="$class$" /class.
/// </summary>
public $class$()
{
InitializeComponent();
}
#endregion

#region Methods
#endregion

#region Events
#endregion

#region Event Handlers
#endregion

#region Nested
#endregion]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>

[Dave Sexton]

Hi Mattias,

In a different post than the one to which you replied I added a different link that is contrary to
your statement. Here it is again:

"Field Usage Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...asp?frame=true

It's quite clear that they are referring to private fields. Scroll to the example at the bottom and
read the nearby bullets.

--
Dave Sexton

"Mattias Sjögren" <ma********************@mvps.orgwrote in message
news:%2********************@TK2MSFTNGP06.phx.gbl.. .

Dave,

>>"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...guidelines.asp

These guidelines are primarily for publicly accessible members.

"The goal of the .NET Framework design guidelines is to encourage
consistency and predictability in *public APIs* while enabling Web and
cross-language integration." (Emphasis added)

http://msdn.microsoft.com/library/de...guidelines.asp

And more clearly

"Casing and naming guidelines apply only to public and protected
identifiers, and privately implemented interface members. Teams are
free to choose their own guidelines for internal and private
identifiers."

http://blogs.msdn.com/kcwalina/archi...28/235232.aspx
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Dave Sexton]

Hi,

Isn't there value in constancy across an entire community as well?

Have you not had to work with code where someone else took their own liberties in choosing what was
appropriate as standards (even if consistent with their organization's standards when the code was
written), leaving you weeping, pulling out hair and going for coffee every 20 minutes?

;)

--
Dave Sexton

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

On Sat, 18 Nov 2006 15:22:18 -0700, "Jonathan Wood"
<jw***@softcircuits.comwrote:

>>
I think consistency is important.

You're dead on target. Regardless of the naming convention used in a
project, consistency is the crux of the biscuit. If the convention
isn't followed it is of no value.

The OP wrote of programmers being confused by different naming
conventions. The responses indicate a great deal of personal
preference but no tales of confusion have been told.

regards
A.G.

[Michael Nemtsev]

Hello Dave,

>Ok, now u was asked to review the code. You got 2 version of source
files from CVS, open them in
diff editor and starting review changes. There is no intellisence. An
catch that difference u
described above is really hard

DSOk, you're definitely correct that intellisense and tooltips aren't
DSalways available :)
DSBut if the method's purpose is known and variable names are
DSmeaningful, I don't see how that could be a problem. It's never
DSbeen a real problem for me, at least not enough to warrant the use
DSof an "_" before all fields in my entire system and to go against a
DSstandard.

Completly agree, but....

DSOutside of VS, as you pointed out, it may be a problem. Definitely
DSnot inside, however.

.... but we returned to my OP :)

What's the most interesting that the widely-accepted standardization is

tuned a little bit to suite company best practice.

So, if someone practice is the intensive codereview (for example PSP metholody
in team) thus this evil "_" only helps u.
In my practice, for some workplaces where I worked, we had spent at least
2-3 hours/per day for code-reviewing, and we found out that "_" really helps
us

Dave, we've got to the same conclusion with good understanding each other.
Suggest to close this discussion :)

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

[LaptopHeaven]

I have been following IDesign's Coding Standards for sometime now.
It's pretty thorough, beyond just naming conventions.

http://www.idesign.net/idesign/DesktopDefault.aspx
http://www.idesign.net/idesign/downl...20Standard.zip

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

[Dave Sexton]

Hi Michael,

>>Ok, now u was asked to review the code. You got 2 version of source
files from CVS, open them in
diff editor and starting review changes. There is no intellisence. An
catch that difference u
described above is really hard

DSOk, you're definitely correct that intellisense and tooltips aren't
DSalways available :)
DSBut if the method's purpose is known and variable names are
DSmeaningful, I don't see how that could be a problem. It's never
DSbeen a real problem for me, at least not enough to warrant the use
DSof an "_" before all fields in my entire system and to go against a
DSstandard.

Completly agree, but....

DSOutside of VS, as you pointed out, it may be a problem. Definitely
DSnot inside, however.

... but we returned to my OP :)

I spend most of my time in VS. The cons outweigh the pros, IMO.

--
Dave Sexton

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

Hello Dave,

>

>What's the most interesting that the widely-accepted standardization is

tuned a little bit to suite company best practice.

So, if someone practice is the intensive codereview (for example PSP metholody in team) thus this
evil "_" only helps u.
In my practice, for some workplaces where I worked, we had spent at least 2-3 hours/per day for
code-reviewing, and we found out that "_" really helps us

Dave, we've got to the same conclusion with good understanding each other. Suggest to close this
discussion :)

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

The docs recommend using "m_" to prefix private fields.

IIRC, nobody here advocated using the "m". Don't you find that to be redundant since you're already
using an "_"?

--
Dave Sexton

"LaptopHeaven" <Co*************@gmail.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

>I have been following IDesign's Coding Standards for sometime now.
It's pretty thorough, beyond just naming conventions.

http://www.idesign.net/idesign/DesktopDefault.aspx
http://www.idesign.net/idesign/downl...20Standard.zip

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

[Dave Sexton]

Hi Michael,

I'm sorry, but I didn't see the end of your post (I'm switching back and forth from newsgroups to
work right now when I build :)

>>What's the most interesting that the widely-accepted standardization is

tuned a little bit to suite company best practice.

So, if someone practice is the intensive codereview (for example PSP metholody in team) thus this
evil "_" only helps u.
In my practice, for some workplaces where I worked, we had spent at least 2-3 hours/per day for
code-reviewing, and we found out that "_" really helps us

Dave, we've got to the same conclusion with good understanding each other. Suggest to close this
discussion :)

That's fine with me. Our experiences obviously differ :)

Thanks for the discussion.

--
Dave Sexton

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

Hello Dave,

>>Ok, now u was asked to review the code. You got 2 version of source
files from CVS, open them in
diff editor and starting review changes. There is no intellisence. An
catch that difference u
described above is really hard

DSOk, you're definitely correct that intellisense and tooltips aren't
DSalways available :)
DSBut if the method's purpose is known and variable names are
DSmeaningful, I don't see how that could be a problem. It's never
DSbeen a real problem for me, at least not enough to warrant the use
DSof an "_" before all fields in my entire system and to go against a
DSstandard.

Completly agree, but....

DSOutside of VS, as you pointed out, it may be a problem. Definitely
DSnot inside, however.

... but we returned to my OP :)

>What's the most interesting that the widely-accepted standardization is

tuned a little bit to suite company best practice.

So, if someone practice is the intensive codereview (for example PSP metholody in team) thus this
evil "_" only helps u.
In my practice, for some workplaces where I worked, we had spent at least 2-3 hours/per day for
code-reviewing, and we found out that "_" really helps us

Dave, we've got to the same conclusion with good understanding each other. Suggest to close this
discussion :)

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

[Jon Skeet [C# MVP]]

Dave Sexton <dave@jwa[remove.this]online.comwrote:

<snip>

I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me

Following standards provides real value through consistency.
Not following any standards makes
development harder by creating friction when moving amongst
different notations and conventions. Making up your own standards makes
interoperability harder, inevitably making development harder as
well - even if its not harder for you it will be for someone else one
day that has to work with your atypical code.

Those are all good reasons for sticking to the standard conventions for
*public* members, but it's worth noting that as far as I'm aware MS
doesn't have any conventions for *private* members. I've seen some
Rotor code which has three different private naming conventions within
the same class - now *that's* something to avoid.

I'd say that so long as your convention for private members is sensible
in itself and consistently applied, it doesn't matter too much what it
is. I use m_ at work and plain camel case for personal development - no
problems.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Dave Sexton <dave@jwa[remove.this]online.comwrote:

The docs recommend using "m_" to prefix private fields.

IIRC, nobody here advocated using the "m". Don't you find that
to be redundant since you're already
using an "_"?

I don't, because we use m_ for instance and g_ for static (at work).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.comwrote:

<snip>

Those are all good reasons for sticking to the standard conventions for
*public* members, but it's worth noting that as far as I'm aware MS
doesn't have any conventions for *private* members.

Looks like either my memory is wrong or the guidelines have been
updated...

Still, I don't think private naming is nearly as much of an issue (in
terms of cross-community standardisation) as non-private naming.

Now bracing, on the other hand...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Dave Sexton]

Hi Jon,

Well, that does make sense then :)

(Note: The last bullet in the link I posted addresses that notation as well).

--
Dave Sexton

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Dave Sexton <dave@jwa[remove.this]online.comwrote:

>The docs recommend using "m_" to prefix private fields.

IIRC, nobody here advocated using the "m". Don't you find that
to be redundant since you're already
using an "_"?

I don't, because we use m_ for instance and g_ for static (at work).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Dave Sexton]

Hi Jon,

Thanks for the input.

Just FYI, Mattias thought the same thing but I've found the docs to prove that hungarian notation
and "_" is NOT recommended for prefixing private fields (this link appears twice already in this
thread). (Also, I think the examples throughout MSDN illustrate this point as well):

"Field Usage Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...asp?frame=true

Scroll to the last example and note the nearby bullets.

--
Dave Sexton

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Dave Sexton <dave@jwa[remove.this]online.comwrote:

><snip>

I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me

Following standards provides real value through consistency.
Not following any standards makes
development harder by creating friction when moving amongst
different notations and conventions. Making up your own standards makes
interoperability harder, inevitably making development harder as
well - even if its not harder for you it will be for someone else one
day that has to work with your atypical code.

Those are all good reasons for sticking to the standard conventions for
*public* members, but it's worth noting that as far as I'm aware MS
doesn't have any conventions for *private* members. I've seen some
Rotor code which has three different private naming conventions within
the same class - now *that's* something to avoid.

I'd say that so long as your convention for private members is sensible
in itself and consistently applied, it doesn't matter too much what it
is. I use m_ at work and plain camel case for personal development - no
problems.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jonathan Wood]

Dave,

Isn't there value in constancy across an entire community as well?

Of course. That's why I started this thread--to try and determine what the
community was doing.

But I think that inconsistency within a single standard is even worse than
inconsistency within the community.

Have you not had to work with code where someone else took their own
liberties in choosing what was appropriate as standards (even if
consistent with their organization's standards when the code was written),
leaving you weeping, pulling out hair and going for coffee every 20
minutes?

After 20 years of programming, you can bet that I have.

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

[Jonathan Wood]

Mattias,

>>"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/de...guidelines.asp

These guidelines are primarily for publicly accessible members.

While they cover private members, I think you raise a good point.

I am now leaning towards an underscore prefix for member variables. If I go
that way, this will have no effect on libraries, etc. I create to be
consumed by others.

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

[Dave Sexton]

Hi Jonathan,

>Isn't there value in constancy across an entire community as well?

Of course. That's why I started this thread--to try and determine what the community was doing.

But I think that inconsistency within a single standard is even worse than inconsistency within
the community.

I agree, but I don't think there is actually any inconsistency in the standard. MSDN's use of the
standard is quite consistent. This seems to be true in their FCL code samples and examples in C#
specs.

It's the external standards that are inconsistent.

>Have you not had to work with code where someone else took their own liberties in choosing what
was appropriate as standards (even if consistent with their organization's standards when the
code was written), leaving you weeping, pulling out hair and going for coffee every 20 minutes?

After 20 years of programming, you can bet that I have.

That amounts to a lot of coffee ;)

(I quit caffeine altogether a couple of years ago so now I just cry and pull out hair - and complain
:)

--
Dave Sexton

[WTH]

Jonathan Wood <jw***@softcircuits.comloquated like no one had ever
loquated before with:

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.

It depends upon several things. The most important of which is your code's
complexity.

If your code writing exhibits a tendency towards writing smaller methods
which in turn call other small method, and they don't have many arguments
you are less likely to be in need of a strong naming schema. Then again, if
you work in a team and the team is not particularly experienced, you may be
in need of a strong naming schema. Personally, for all of the 'at work'
code I wrote, I use a very strong naming schema left over from my Microsoft
days and I require my team to use it as well, in some ways this is a pain in
the a** for the developers, but anybody can read anybody else's code far
more easily than when I didn't require this level of discipline. For
consulting work, I simply use whatever standards the customer requires (they
usually have coding groups and standards already) so that my code fits right
in.

It's all toolbox and people tend to get zealous about little things like
that (and languages for instance ;).)

Example of a strong schema?

Can you tell which elements in the method signature below are incoming
and/or outgoing?

bool LocalizeMenuResource( string in_strMenuName, unsigned int
in_nResourceID, string out_strLocalizedText )

An example of a strong class member name 'string m_strDBConnectionString'

One of the things I constantly strive to avoid doing myself is writing
abbreviated variable names unless it is an extremley obvious word like 'DB'.
Sometimes this can look ridiculous; however, many times I've had new team
members comment on how easy it is to understand what the code is doing
because of this. It appears to make more impact on people who know less
about the codebase than those who already have a general feel for what's
going on and how each team members contributes code.

Again, it primarily depends on your style of coding, what type of team
you're in, the dynamism of that team, et cetera. These are all things, btw,
that should effect your methodology as a whole as well.

WTH

--
"When you have a Liverpool shirt on your back as part of the squad, you
will do anything to make sure you preserve what it stands for." -
Gérard Houllier

[Dale]

Actually, I was wrong. I guess I hadn't written a constructor since I slept
last. All my constructors that have parameters named just like fields
utilize "this." in the assignment.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Jonathan Wood" wrote:

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

[WTH]

Jonathan Wood <jw***@softcircuits.comloquated like no one had ever
loquated before with:

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.

I would suggest that the problem above is not managing to specify to the
compiler which myInt is which, but that you need to name your arguments
differently. Getting it to compile correctly is one thing, but not the only
thing.

WTH

--
"One of the things I am in the habit of saying is that the only place
success comes before work is in the dictionary." - Gérard Houllier

[Dave Sexton]

Hi,

<snip>

Example of a strong schema?

Can you tell which elements in the method signature below are incoming and/or outgoing?

Yes, they are all "incoming" and one is inappropriately named as "out_strLocalizedText" ;)

bool LocalizeMenuResource( string in_strMenuName, unsigned int in_nResourceID, string
out_strLocalizedText )

You must use the C# "out" keyword to pass the string reference as a reference and in the calling
code you must include the "out" keyword as well:

bool LocalizeMenuResource(string menuName, uint resourceID, out string localizedText) { ... }

string localizedText;

if (LocalizeMenuResource("A Menu", 40, out localizedText))
{
// do something with localizedText
}

An example of a strong class member name 'string m_strDBConnectionString'

m_: I won't beat a dead horse
str: Yes, it's a string (ConnectionString to be exact).
Intellisense and a tooltip will also show that
DB: What else would a connection string be for?
(This is especially obvious if it appears in a DAL, for instance)

string connectionString = "Data Source...";

Much nicer, IMO.

<snip>

--
Dave Sexton

[WTH]

Dave Sexton <dave@jwa[remove.this]online.comloquated like no one had ever
loquated before with:

Hi,

<snip>

>Example of a strong schema?

Can you tell which elements in the method signature below are
incoming and/or outgoing?

Yes, they are all "incoming" and one is inappropriately named as
"out_strLocalizedText" ;)

>bool LocalizeMenuResource( string in_strMenuName, unsigned int
in_nResourceID, string out_strLocalizedText )

You must use the C# "out" keyword to pass the string reference as a
reference and in the calling code you must include the "out" keyword
as well:

Yes Dave, the exact semantics of a particular CIL implementation was not the
point of my post ;). Cheeky monkey.

WTH

>
bool LocalizeMenuResource(string menuName, uint resourceID, out
string localizedText) { ... }
string localizedText;

if (LocalizeMenuResource("A Menu", 40, out localizedText))
{
// do something with localizedText
}

>An example of a strong class member name 'string
m_strDBConnectionString'

m_: I won't beat a dead horse
str: Yes, it's a string (ConnectionString to be exact).
Intellisense and a tooltip will also show that
DB: What else would a connection string be for?
(This is especially obvious if it appears in a DAL, for
instance)
string connectionString = "Data Source...";

Much nicer, IMO.

<snip>

Again, my point is that it isn't about what's "nice" or what's "convenient"
or what you or I would personally prefer (I myself began as an
Irix/SunOS/Solaris developer once upon a time in a galaxy...), it is about
what is the best for your team/company/product/customer.

BTW, the problem with using a member named 'connectionString' is when you
have a method with a local string relating to a connection and also need to
refer to your class' connection string. Most people would rather
immediately be able to tell which one belonged to the object instance and
which one was local (I say this because I presume you also dislike
l_strConnectionString.)

WTH

--
"One of the things I am in the habit of saying is that the only place
success comes before work is in the dictionary." - Gérard Houllier

[Dave Sexton]

Hi,

>>Example of a strong schema?

Can you tell which elements in the method signature below are
incoming and/or outgoing?

Yes, they are all "incoming" and one is inappropriately named as
"out_strLocalizedText" ;)

>>bool LocalizeMenuResource( string in_strMenuName, unsigned int
in_nResourceID, string out_strLocalizedText )

You must use the C# "out" keyword to pass the string reference as a
reference and in the calling code you must include the "out" keyword
as well:

Yes Dave, the exact semantics of a particular CIL implementation was not the point of my post ;).
Cheeky monkey.

Ah, well this is a C# newsgroup, so naturally I just thought...

<snip>

>string connectionString = "Data Source...";

Much nicer, IMO.

<snip>

Again, my point is that it isn't about what's "nice" or what's "convenient" or what you or I would
personally prefer (I myself began as an Irix/SunOS/Solaris developer once upon a time in a
galaxy...), it is about what is the best for your team/company/product/customer.

Well, that is a different discussion altogether.

BTW, the problem with using a member named 'connectionString' is when you have a method with a
local string relating to a connection and also need to refer to your class' connection string.
Most people would rather immediately be able to tell which one belonged to the object instance and
which one was local (I say this because I presume you also dislike l_strConnectionString.)

Debating that point has been prevalent in this thread.

And yes, I dislike the "l_" and "str".

--
Dave Sexton

[WTH]

Dave Sexton <dave@jwa[remove.this]online.comloquated like no one had ever
loquated before with:

Hi,

>>>Example of a strong schema?

Can you tell which elements in the method signature below are
incoming and/or outgoing?

Yes, they are all "incoming" and one is inappropriately named as
"out_strLocalizedText" ;)
bool LocalizeMenuResource( string in_strMenuName, unsigned int
in_nResourceID, string out_strLocalizedText )

You must use the C# "out" keyword to pass the string reference as a
reference and in the calling code you must include the "out" keyword
as well:

Yes Dave, the exact semantics of a particular CIL implementation was
not the point of my post ;). Cheeky monkey.

Ah, well this is a C# newsgroup, so naturally I just thought...

Indeed, I should have been clearer.

>
<snip>

>>string connectionString = "Data Source...";

Much nicer, IMO.

<snip>

Again, my point is that it isn't about what's "nice" or what's
"convenient" or what you or I would personally prefer (I myself
began as an Irix/SunOS/Solaris developer once upon a time in a
galaxy...), it is about what is the best for your
team/company/product/customer.

Well, that is a different discussion altogether.

>BTW, the problem with using a member named 'connectionString' is
when you have a method with a local string relating to a connection
and also need to refer to your class' connection string. Most people
would rather immediately be able to tell which one belonged to the
object instance and which one was local (I say this because I
presume you also dislike l_strConnectionString.)

Debating that point has been prevalent in this thread.

And yes, I dislike the "l_" and "str".

;)

--
"The fans here are the greatest in the land. They know the game and
they know what they want to see. The people on the Kop make you feel
great - yet humble." - Bill Shankly

[Michael C]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%23QnoN2%

But if the method's purpose is known

Notice 1 very important word in you sentence, "IF". If the methods purpose
is know then maybe not but when these conventions are most important is when
you don't know the code.

You might feel that it's much clearer in the latter version whether "_r"
is a local or a field, but does that provide any value? After all, if you
understand the method then it should be obvious, and anyway there really
is no ambiguity here. Why even assume that "r", in the first example, is
a local variable?

What else could it be? It can't be a function because they're all capitals.
It can't be a module level if they've got an underscore. The only other
possibility is a parameter but they're very similar to local vars anyway and
very easy to determine what they are.

Michael

[Dave Sexton]

Hi Michael,

>But if the method's purpose is known

Notice 1 very important word in you sentence, "IF". If the methods purpose is know then maybe not
but when these conventions are most important is when you don't know the code.

That's a good point, but before I review a class I automatically browse for a list of private fields
first to keep as a reference. That's why I always code all private fields together. When I browse
upon a class that I haven't seen in a while I can just pop open a Private / Protected region and
there is no confusion at all.

I do see the benefit of "_" in cases like that; however, I don't think it's necessary if you
organize the structure of your document appropriately.

>You might feel that it's much clearer in the latter version whether "_r" is a local or a field,
but does that provide any value? After all, if you understand the method then it should be
obvious, and anyway there really is no ambiguity here. Why even assume that "r", in the first
example, is a local variable?

What else could it be? It can't be a function because they're all capitals. It can't be a module
level if they've got an underscore. The only other possibility is a parameter but they're very
similar to local vars anyway and very easy to determine what they are.

I mean, in the context of a method that assigns randomized values to r, g, and b in a Color class,
the assignments are obviously to fields. I find it to be rare that confusion exists whether a
variable is a field or a local when descriptive naming conventions are used and in a meaningful
context, even without the support of intellisense and tooltips. Designing methods to be succinct
helps too.

--
Dave Sexton

[Registered User]

On Sun, 19 Nov 2006 10:46:20 -0500, "Dave Sexton"
<dave@jwa[remove.this]online.comwrote:

>Hi,

Isn't there value in constancy across an entire community as well?

Yes but all members of the community must choose to agree and
participate. Some will always consider the result not worth the
effort.

>Have you not had to work with code where someone else took their own liberties in choosing what was
appropriate as standards (even if consistent with their organization's standards when the code was
written), leaving you weeping, pulling out hair and going for coffee every 20 minutes?

Unfortunately several times yes. Not once did a poor or non-existent
naming standard play a role my angst. On the other hand questionable
design and sloppy code will make me scream, not everyone is or tries
to be a craftsman. Once the billable hour of bitching and moaning is
over I resolve the issues as quickly and efficiently as possible.

regards
A.G.

[Dustin Campbell]

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 prefix instance fields with "m_" (for "member") and static fields with
"g_" (for "global").

BTW, the IDesign C# Coding Standard (www.idesign.net) also recommends prefixing
with "m_".

Just my 2 cents.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi,

>>Isn't there value in constancy across an entire community as well?

Yes but all members of the community must choose to agree and
participate. Some will always consider the result not worth the
effort.

Not all need to participate in standards for them to be appropriate. Look at the situation with IE
adopting new standards, for instance. If the standards have any merit they will inevitably be
adopted by most, given enough time.

So I don't think a potential for nonconformists is a valid excuse to ignore a community standard.
Now, if the standard itself doesn't have any merit, that's a different story :)

>>Have you not had to work with code where someone else took their own liberties in choosing what
was
appropriate as standards (even if consistent with their organization's standards when the code was
written), leaving you weeping, pulling out hair and going for coffee every 20 minutes?

Unfortunately several times yes. Not once did a poor or non-existent
naming standard play a role my angst. On the other hand questionable
design and sloppy code will make me scream, not everyone is or tries
to be a craftsman. Once the billable hour of bitching and moaning is
over I resolve the issues as quickly and efficiently as possible.

Then our experience differs here, somewhat. I agree, however, that bad design and irregular coding
styles are frustrating as well.

--
Dave Sexton

[Jonathan Wood]

Dave,

>But I think that inconsistency within a single standard is even worse
than inconsistency within the community.

I agree, but I don't think there is actually any inconsistency in the
standard. MSDN's use of the standard is quite consistent. This seems to
be true in their FCL code samples and examples in C# specs.

I was referring to the suggested practice of prefixing member variables with
"this." but doing so only when it is deemed as needed, and not doing it in
other cases.

That amounts to a lot of coffee ;)

(I quit caffeine altogether a couple of years ago so now I just cry and
pull out hair - and complain :)

<g>

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

[Jonathan Wood]

Interesting. I assume you aware that Microsoft's standards specifically
dictate that you do not use these prefixes.

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

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>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 prefix instance fields with "m_" (for "member") and static fields with
"g_" (for "global").

BTW, the IDesign C# Coding Standard (www.idesign.net) also recommends
prefixing with "m_".

Just my 2 cents.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Jonathan,

>>But I think that inconsistency within a single standard is even worse than inconsistency within
the community.

I agree, but I don't think there is actually any inconsistency in the standard. MSDN's use of
the standard is quite consistent. This seems to be true in their FCL code samples and examples
in C# specs.

I was referring to the suggested practice of prefixing member variables with "this." but doing so
only when it is deemed as needed, and not doing it in other cases.

I don't see that as being worse at all. "this." is a tool that I use to help the compiler resolve
otherwise ambiguous references. I don't use it when it's pointless. Worse than an entire community
choosing their own, internal standards? Definitely not.

<snip>

--
Dave Sexton