underscores on variable names

  • Thread starter Thread starter Peter Kirk
  • Start date Start date
P

Peter Kirk

Hi

I am looking at some C# code, and can see in some of the classes there are
instance variables whose names start with an underscore, for example:

private string _projectId;

Is there a reason for using underscores like this in C#?

Thanks,
Peter
 
Peter,

Personal preference, the most I see used at the moment is camelCase or other
styles like that.

Cor
 
I am looking at some C# code, and can see in some of the classes there are
instance variables whose names start with an underscore, for example:

private string _projectId;

Is there a reason for using underscores like this in C#?
Click to expand...

Some folks use it as a prefix to distinguish a field from a property without
an underscore; Delphi programmers use a convention of prefixing fields with
'F', I have also seen ''m' used in C# (to denote memory I guess ?)

Joanna
 
Just google for "C# naming conventions" or "C# coding style guide", you'll
find lots of infos :-)
 
Note that this practice isn't official because it isn't CLR compliant.

I use the following naming conventions in my code. Similar styles are used
by others;

Underbar denotes a field. Fields are ALWAYS protected or private. The name
is the same as the property name but has a preceeding underbar and a lower
case initial letter such as _myInteger

Property names use the name of the property backer variable witout the
underbar and with the initial capital letter such as MyInteger.

A property is structured so:

protected int _myInteger;

public int MyInteger
{
get{return _myInteger;}
set{_myinteger=value;}
}

All names are CamelCased

This prctice is particularly useful if you need to provide code in both C#
and VB as I do often because I can write in C# and convert to VB using a
conversion tool. If you don't use the underbar in this way VB, which is too
stupid to recognise the difference between lower-case and upper-case
characters, chokes on the names myInteger and MyInteger being the same.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
I use the underscore, not to distinguish a field from a property,
but to "underscore" that this is a private member.
Some use "m" or "m_" but they all use it to say that this is a private field
member.
And some of us does'nt use this notation at all, but rather use "this"
keyword or nothing at all.

This is partly to make it easier to read, and partly to distinguish local
variables
from private members, which would otherwise potentially have the same name.
class A
{
private int value;
/* Sets the private member to the value specified. */
void SetValue ( int value )
{
// Would not work since we are assigning the parameter variable.
value = value;
// OK. This is a way to distuingish a local variable
// and a private member variable that have the same name.
this.value = value;
// OK (assuming the private member "value" was renamed "_value").
// If we always use some special character as a prefix on private
members,
// we will never have this "issue".
_value = value;
}
}
 
The m prefix is a holdover from the days of MFC when the prefix m denoted a
member variable to distinguich them from local variables.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
Some folks use it as a prefix to distinguish a field from a property
without
an underscore; Delphi programmers use a convention of prefixing fields
with
'F', I have also seen ''m' used in C# (to denote memory I guess ?)
Click to expand...
"module" actually, if memory serves. It would be an example of scope
specification in a hungarian variable name: m_lpzstrName = module field that
is a long(I *think*) pointer to a null terminated string. I don't recall for
sure what the l meant in lp.

Anyway, the common prefixes I can recall are
p for parameter,
m for module,
g for global,

probably others I don't know.
 
Bob,

And that "m" or something else is needed in by instance VBNet to distinct
the value from the property because that is case Sensitive.

Although it can give strange effects when that "m" is not used in C# as well
with public values because it is not CLS compliant than. (However a little
bit strange coding).

:-)

Cor
 
Bob,

I was making my message to you in this thread before I saw this one.

:-)

Sorry

Cor
 
Peter,
In addition to the other comments:

The .NET Design Guidelines for Class Library Developers recommend not
including a prefix, instead simply use projectId field for the ProjectId
Property.

http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconFieldUsageGuidelines.asp

However this guideline has major problems for VB.NET developers (as Bob &
others have noted), plus I find it at odds with the Case Sensitivity
guideline, as IMHO there should be a guideline about not having two members
(method & property, method & nested class, method & delegate, method &
event, event & property, property & field...) that differ only by case.

http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconCaseSensitivity.asp


| Is there a reason for using underscores like this in C#?

I prefer to use m_ as the prefix for field members as that is what I learned
in C++. Also as Eric mentions in his blog below it (a prefix, any prefix)
allows me to know instanly whether an identifier was a field or it was a
parameter or local. (Knowing the difference between parameter & local is
generally not that important to me as my methods are normally shorter).

http://blogs.msdn.com/ericgu/archive/2005/03/09/390791.aspx

Hope this helps
Jay

| Hi
|
| I am looking at some C# code, and can see in some of the classes there are
| instance variables whose names start with an underscore, for example:
|
| private string _projectId;
|
| Is there a reason for using underscores like this in C#?
|
| Thanks,
| Peter
|
|
 
We have reluctantly adopted the initial underscore coding standard here
as well, after resisting it for some time.

What finally pushed us over the edge was Intellisense, which had the
bad habit of choosing the public property name instead of the private
member name (or vice versa) because they were so similar (or differed
only by case).

The underscore nicely separates the two groups of names in Intellisense
pick lists, making it unlikely that Intellisense will "helpfully" pick
the wrong name for us.

I still hate the way it looks, though. Ugly, ugly, ugly.... :(
 
Bruce Wood said:
We have reluctantly adopted the initial underscore coding standard here
as well, after resisting it for some time. ....
I still hate the way it looks, though. Ugly, ugly, ugly.... :(
Click to expand...

You get used to it after a while, promise ;D
 
Sean Hederman said:
You get used to it after a while, promise ;D
Click to expand...

One could get used to a prefix consisting of "thisIsAPrivateField" as well,
but that doesn't make it more aesthetically pleasing. ;)
 
Back
Top