Member Variables Naming Convention

[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/d...html/cpconfieldusageguidelines.asp?frame=true

Scroll to the last example and note the nearby bullets.

 

[Dave Sexton]

Hi Jon,

Well, that does make sense then

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

 

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

Mattias,

"Naming Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.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.

 

[Dave Sexton]

Hi Jonathan,

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.

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

 

[WTH]

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

 

[Guest]

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

 

[WTH]

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

 

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

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>

 

[WTH]

Hi,



Yes, they are all "incoming" and one is inappropriately named as
"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
}


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

 

[Dave Sexton]

Hi,

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

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

 

[WTH]

Hi,


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

Indeed, I should have been clearer.

Well, that is a different discussion altogether.


Debating that point has been prevalent in this thread.

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

 

[Michael C]

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,

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.

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.

 

[Registered User]

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,

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

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.

 

[Jonathan Wood]

Dave,

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]

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

 

[Dave Sexton]

Hi Jonathan,

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>