469,330 Members | 1,335 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,330 developers. It's quick & easy.

Member Variables Naming Convention

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
Nov 17 '06
114 6842
Dave Sexton wrote:
>>>But I think that inconsistency within a single standard is even worse than inconsistency within
the community.
Not a direct reply to this message, or even remotely related to the
thread, but is there any chance you could configure your newsreader to
wrap lines at a more conventional 72-76 characters? You're currently
posting at around 100 characters per line, which is making your posts
very difficult to follow, even though this whole thread is incredibly
interesting :)

--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk

Programming, n: A pastime similar to banging one's head
against a wall, but with fewer opportunities for reward.
Nov 20 '06 #101
Hi Dylan,

Yes, thanks for bringing that point to my attention - I didn't even realize
that it mattered :p

I've played around with that setting a few times trying to find a
comfortable place, but none has been found that I like. The lack of markup
in NNTP is really driving me crazy :)

Is this better?

--
Dave Sexton

"Dylan Parry" <us****@dylanparry.comwrote in message
news:4s************@mid.individual.net...
Dave Sexton wrote:
>>>>But I think that inconsistency within a single standard is even worse
than inconsistency within
the community.

Not a direct reply to this message, or even remotely related to the
thread, but is there any chance you could configure your newsreader to
wrap lines at a more conventional 72-76 characters? You're currently
posting at around 100 characters per line, which is making your posts
very difficult to follow, even though this whole thread is incredibly
interesting :)

--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk

Programming, n: A pastime similar to banging one's head
against a wall, but with fewer opportunities for reward.

Nov 20 '06 #102
Interesting. I assume you aware that Microsoft's standards
specifically dictate that you do not use these prefixes.
Of course I'm aware of the Microsoft standards. However, AFAICT, Microsoft's
naming guidelines are really only for public-visibly fields. They are intended
to allow client code to have a consistent experience when using any .NET
API.

IMO, any static or instance field should be private. To do otherwise would
break good encapsulation practice and a bad idea (the only exception is using
a static, read-only field for a predefined object instance). If you *do*
have protected or public fields, you should certainly follow Microsoft's
guidelines for consistency. But, since I don't do that, I choose to use my
own conventions.

If you use the .NET Reflector to example the BCL assemblies, you'll find
that Microsoft also does the same thing. For example, looking at System.ApplicationId
reveals the following fields:

private string m_culture;
private string m_name;
private string m_processorArchitecture;
internal byte[] m_publicKeyToken;
private Version m_version;

But, it's not consistent. System.Guid has these fields:

public static readonly Guid Empty;
private int _a;
private short _b;
private short _c;
private byte _d;
private byte _e;
private byte _f;
private byte _g;
private byte _h;
private byte _i;
private byte _j;
private byte _k;

System.String:

private const int alignConst = 3;
private const int charPtrAlignConst = 1;
public static readonly string Empty;
[NonSerialized]
private int m_arrayLength;
[NonSerialized]
private char m_firstChar;
[NonSerialized]
private int m_stringLength;
private const int TrimBoth = 2;
private const int TrimHead = 0;
private const int TrimTail = 1;
internal static readonly char[] WhitespaceChars;

System.Collections.ArrayList:

private const int _defaultCapacity = 4;
private object[] _items;
private int _size;
[NonSerialized]
private object _syncRoot;
private int _version;
private static readonly object[] emptyArray;

So, Microsoft only consistently follow convention when the field is going
to be consumed as an API. In fact, they sometimes even break that. Consider
the fields from System.Diagnostics.StackTrace:

private StackFrame[] frames;
private int m_iMethodsToSkip;
private int m_iNumOfFrames;
public const int METHODS_TO_SKIP = 0;

Notice that there's a public constant in ALL CAPS. Oops!

Microsoft *does* have this statement in the Field Usage Guidelines document
(http://msdn.microsoft.com/library/de...idelines.asp):

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

However, consider the following quote from "Framework Design Guidelines:
Conventions, Idions, and Patterns for Reusable .NET Libraries", Section 3.6.4
("Naming Fields"), pg. 64:

"The field naming guidelines apply to static public and protected fields.
Internal and private fields are not covered by guidelines and public or protected
instance fields are not allowed according to the member design guidelines
described in Chapter 5."

Last in the same section, it says "do not use 'g_' or 's_' to distinguish
static versus non-static fields". However, it already specified that the
guidelines do not apply to private fields.

Personally, I see distinguishing between static and instance fields as a
very useful convention. It can reduce mistakes and increase usability if
you are looking at a method that contains code which mixes instance and static
field access. The desire to distinguish fields from locals and parameters
is driven by the same purpose. So, unless Microsoft actually publishes a
*reason* (e.g. disadvantage) to name static and instance fields the same,
I'm going to continue to distinguish them.

Even Jeffrey Richter prefixes with "m_" and "s_" in the CLR via C# book for
private instance and static fields respectively (cf pg. 180).

And finally, to find a case where Microsoft distinguishes between instance
and static fields, you don't have to look any further than System.Threading.Thread:

private IntPtr DONT_USE_InternalThread;
private Context m_Context;
private CultureInfo m_CurrentCulture;
private CultureInfo m_CurrentUICulture;
private Delegate m_Delegate;
private ExecutionContext m_ExecutionContext;
private string m_Name;
private int m_Priority;
private object m_ThreadStartArg;
private int[] m_ThreadStaticsBits;
private object[][] m_ThreadStaticsBuckets;
private static LocalDataStoreMgr s_LocalDataStoreMgr;
private static object s_SyncObject;
private const int STATICS_BUCKET_SIZE = 0x20;
Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 20 '06 #103
Dave Sexton wrote:
Yes, thanks for bringing that point to my attention - I didn't even realize
that it mattered :p
You're welcome! I'm glad you took it positively, as quite often people
will become complete morons when you bring up a valid point about their
posting style ;)
Is this better?
Much better. Cheers,

--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk

Programming, n: A pastime similar to banging one's head
against a wall, but with fewer opportunities for reward.
Nov 20 '06 #104
Dustin,
>Interesting. I assume you aware that Microsoft's standards
specifically dictate that you do not use these prefixes.

Of course I'm aware of the Microsoft standards. However, AFAICT,
Microsoft's naming guidelines are really only for public-visibly fields.
They are intended to allow client code to have a consistent experience
when using any .NET API.
Well, I wouldn't say "of course" since I don't know you personally. I was
just curious. However, while I do think the standard is most significant in
the context of public interfaces, the standards are very specific about
private members as well.
IMO, any static or instance field should be private. To do otherwise would
break good encapsulation practice and a bad idea (the only exception is
using a static, read-only field for a predefined object instance). If you
*do* have protected or public fields, you should certainly follow
Microsoft's guidelines for consistency. But, since I don't do that, I
choose to use my own conventions.
Actually, their guildelines also are very specific in recommending against
protected or public fields. :-)
If you use the .NET Reflector to example the BCL assemblies, you'll find
that Microsoft also does the same thing.
Yes, that is interesting. Note that I'm a long-time programmer who uses MFC
a lot. So I'm very comfortable with the "m_" prefix and reasons associate
with it's use. So I'm not really looking for a rehash of those issues. I
just started this thread to determine what the standard appears to be. And
I've already stated in this thread that I'm leaning towards using "_". I was
just curious if you knew what Microsoft was recommending.

As far as Microsoft not following that standard, I strongly suspect that the
standard and .NET libraries were developed at the same time, and so the
standard had not been written when much of that library was written. Not
that it matters that much.
Personally, I see distinguishing between static and instance fields as a
very useful convention.
Yes, I've been arguing that this entire thread.
It can reduce mistakes and increase usability if you are looking at a
method that contains code which mixes instance and static field access.
The desire to distinguish fields from locals and parameters is driven by
the same purpose. So, unless Microsoft actually publishes a *reason* (e.g.
disadvantage) to name static and instance fields the same, I'm going to
continue to distinguish them.
Yeah, and while I'm ready to abort use of "m_", I continue to lean towards
using a single underscore prefix for private variables.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Nov 20 '06 #105
here is a link to the Microsoft guidelines for naming conventions:
http://msdn.microsoft.com/library/de...ry/en-us/cpgen
ref/html/cpconnamingguidelines.asp
I follow these.
Hey Mark,

That is an older guideline from the old MSDN library. The most current one
is located here: http://msdn2.microsoft.com/en-us/library/ms229042.aspx.
It clears up certain areas that are a bit vague.

Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 20 '06 #106
Well, I wouldn't say "of course" since I don't know you personally. I
was just curious.
I didn't mean "of course" in a condescending way or anything. It was more
conversational. :-)
However, while I do think the standard is most
significant in the context of public interfaces, the standards are
very specific about private members as well.
Could you post a link to where the standards are specific about private fields?
The only link in this thread references the older ".NET Framework General
Reference: Naming Guidelines". You should really be using the newer MSDN
library at http://msdn2.microsoft.com/library. The newer ".NET Framework
Developer's Guide: Guidelines for Names" are located here: http://msdn2.microsoft.com/en-us/library/ms229002.aspx.

In this newer guideline, I can not find any indication of how private fields
should be named. Here is the information on naming fields from http://msdn2.microsoft.com/en-us/library/ms229012.aspx:

"Names of Fields
The naming guidelines for fields apply to static public and protected fields.
You should not define public or protected instance fields. For more information,
see Field Design.

Do use Pascal casing in field names.
Do name fields with nouns or noun phrases.
Do not use a prefix for field names. For example, do not use g_ or s_ to
distinguish static versus non-static fields."

The important sentence is the very first one: "The naming guidelines for
fields apply to static public and protected fields." IOW, you are free to
use any style for instance fields that you want because the guidelines also
state that use shouldn't ever have anything other than private instance fields.
Also, the stipulation that you shouldn't distinguish between static and non-static
fields only applies to public and protected fields.

Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 20 '06 #107
Dustin,
The important sentence is the very first one: "The naming guidelines for
fields apply to static public and protected fields." IOW, you are free to
use any style for instance fields that you want because the guidelines
also state that use shouldn't ever have anything other than private
instance fields. Also, the stipulation that you shouldn't distinguish
between static and non-static fields only applies to public and protected
fields.
Well that's just great. What do they do, create a new link with new content
each time the standard is updated. This is getting a bit too confusing for
me.

I don't seem to be finding in those links what I read before. I know there
were subtopics with names about private variables as I recall it.

At any rate, your point is well taken, particular if what I read before has
been changed.

To sum up: I do not like the "this." prefix for member variables. I am going
to use the "_" prefix for member variables. For public symbols, I will try
and follow the standards outline by Microsoft.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Nov 20 '06 #108
dave,
>It's quite clear that they are referring to private fields. Scroll to the example at the bottom and
read the nearby bullets.
I don't think that's clear at all, since those bullets don't
specifically say anything about private fields. They make perfect
sense for public and protected fields (in the few cases you expose
such). And the updated guidelines on MSDN2 that others have referred
to spells this out more clearly.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 20 '06 #109
Hi Dustin,

<snip>
Microsoft *does* have this statement in the Field Usage Guidelines
document
(http://msdn.microsoft.com/library/de...idelines.asp):

"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."
Don't just discount the example immediately above that line, which uses
private members. Also, don't forget the code samples in the C#
specification documents and FCL documents on MSDN. I can't remember ever
seeing the use of prefixes on private or public, static or instance fields
in any code sample. That goes for "m_", "g_", "s_", and "_" alone.

<snip>
So, Microsoft only consistently follow convention when the field is going
to be consumed as an API. In fact, they sometimes even break that.
I guess the (probably C++) programmers that were coding the framework were
allowed to use those conventions because it's what they were used to, and as
Jonathan wrote, the standards were probably not finalized yet anyway. So
they didn't eat their own dog food in the private members of framework
assemblies, but that doesn't mean they aren't recommending that others
follow those standards.

<snip>

--
Dave Sexton

Nov 20 '06 #110
Well that's just great. What do they do, create a new link with new
content each time the standard is updated. This is getting a bit too
confusing for me.
At least they've put it in print now: http://www.amazon.com/Framework-Desi...e=UTF8&s=books.
The text in the book is consistent with what's at MSDN2.
I don't seem to be finding in those links what I read before. I know
there were subtopics with names about private variables as I recall
it.

At any rate, your point is well taken, particular if what I read
before has been changed.
AFAICT, things have actually been loosened a bit to leave room for personal
style. IOW, feel free to code the way you want *except* when it is visible
to other client code. In that case, use Microsoft's guidelines so that client
code has a consistent experience.
To sum up: I do not like the "this." prefix for member variables. I am
going to use the "_" prefix for member variables. For public symbols,
I will try and follow the standards outline by Microsoft.
Yeah! Sounds good!

Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 20 '06 #111
Dustin,
At least they've put it in print now:
http://www.amazon.com/Framework-Desi...e=UTF8&s=books.
The text in the book is consistent with what's at MSDN2.
Cool. Probably a good purchase if you plan to write .NET libraries.
AFAICT, things have actually been loosened a bit to leave room for
personal style. IOW, feel free to code the way you want *except* when it
is visible to other client code. In that case, use Microsoft's guidelines
so that client code has a consistent experience.
Yeah, there's a lot of little quirks in languages like MFC that have built
up over the years. Of course, there was stuff like the "m_" prefix right
from the start. There is also the _T() macro, and two versions of every API
and CRT routine that works with strings. So it's clear to me that one goal
of .NET was to clean things up a bit, and one can only assume that's why
there is this push to avoid Hungarian and other prefixes. Note that I do not
have a problem with cleaning things up a bit. ;-)

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Nov 20 '06 #112
Hi Dustin,
That text is actually from the old MSDN library though. Try looking for
the same thing in MSDN2 in the latest design guidelines.
I realized that it wasn't from msdn2 but I didn't realize Microsoft was
actually changing their policy (as you've brought to my attention in a
related post in this thread). So that just leaves me with all of the code
samples in FCL documentation and C# specs, which I admit are hardly
standards, but the styles used are sometimes adopted by beginning developers
and certainly don't use prefixes.

I feel they're going backwards with this new, "public / protected - only"
policy. I think it's a shame that Microsoft doesn't keep the standardized
private naming conventions as well. This means that people are going to
feel free to use names like, "m_strDBConnectionString", which was presented
in this thread.

Prepare to deal with some confusing and ugly field names when maintaining
legacy, managed code in the next 5 years. Brings back memories. :)

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...
>>Microsoft *does* have this statement in the Field Usage Guidelines
document
(http://msdn.microsoft.com/library/de...rary/en-us/cpg
enref/html/cpconfieldusageguidelines.asp):

"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."
Don't just discount the example immediately above that line, which
uses private members. Also, don't forget the code samples in the C#
specification documents and FCL documents on MSDN. I can't remember
ever seeing the use of prefixes on private or public, static or
instance fields in any code sample. That goes for "m_", "g_", "s_",
and "_" alone.

Hi Dave,
That text is actually from the old MSDN library though. Try looking for
the same thing in MSDN2 in the latest design guidelines.

Best Regards,
Dustin Campbell
Developer Express Inc.


Nov 20 '06 #113
Hi Mattias,

Yes, it's come to my attention that Microsoft's policies may have changed.

But, those bullets appear immediately after an example that uses private
fields without prefixes. I think it's clear.

--
Dave Sexton

"Mattias Sjögren" <ma********************@mvps.orgwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
dave,
>>It's quite clear that they are referring to private fields. Scroll to the
example at the bottom and
read the nearby bullets.

I don't think that's clear at all, since those bullets don't
specifically say anything about private fields. They make perfect
sense for public and protected fields (in the few cases you expose
such). And the updated guidelines on MSDN2 that others have referred
to spells this out more clearly.
Mattias

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

Nov 20 '06 #114
Yes, it's come to my attention that Microsoft's policies may have
changed.

But, those bullets appear immediately after an example that uses
private fields without prefixes. I think it's clear.
I agree with Dave that it is clear in the documentation that was presented
when you consider the example code. The problem is that it is older documentation
and newer docs are available.

Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 20 '06 #115

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.