Is it good or bad practice to prefix private class variables with underscore in C#

[PromisedOyster]

Many in our development team have came from a C++ background and are in
the practice of prefixing private class variables with an underscore to
improve readability and avoid naming collisions with local variables
and parameters. This has become our standard.

ie private string _name;

as opposed to:

ie private string name;

However, one of the newer guys has informed us that this is bad
practice.

Is this good, bad or no big deal?

 

[Kürsat]

I think consistant naming is more important than naming style.

I like and use underscores when I write C/C++ code. I don't know why but I
think underscore is created for C/C++

Enter C#, underscore usage is trivial I think.

 

[Jon Skeet [C# MVP]]

Many in our development team have came from a C++ background and are in
the practice of prefixing private class variables with an underscore to
improve readability and avoid naming collisions with local variables
and parameters. This has become our standard.

ie private string _name;

as opposed to:

ie private string name;

However, one of the newer guys has informed us that this is bad
practice.

Is this good, bad or no big deal?

No big deal, so long as you're consistent. For a long time I worked at
a company which didn't use prefixes at all. The company I now work for
use m_ for instance fields and g_ for static fields. When I'm doing
personal development I tend not to put any prefixes on.

Methods should generally be short enough that it's obvious where a name
comes from, IMO, so prefixes aren't necessary - but if there's a big
preference for it, go with the flow.

Jon

 

[Jani Järvinen [MVP]]

Hi Oyster,

as other have said, consistency is the key. The only thing that comes into
mind against using underscores is that some development systems and
libraries tend to use the underscore to mark "special", "hidden" or
"internal" features.

Using an underscore in the beginning might confuse a developer with such
special methods/classes/fields/whatever.

But in C#, this shouldn't be an issue.

--
Regards,

Mr. Jani Järvinen
C# MVP
Helsinki, Finland
(e-mail address removed)
http://www.saunalahti.fi/janij/

 

[Phil]

Hi Oyster,

as other have said, consistency is the key. The only thing that comes into
mind against using underscores is that some development systems and
libraries tend to use the underscore to mark "special", "hidden" or
"internal" features.

Whatever naming convention you use, it is important to use names that
distinguish between fields, parameters and properties. You can
introduce annoying and difficult to predict bugs otherwise. I recently
got caught by this one

public string Item { get; set; }

public void MyMethod(string Item) {
Item = Item;
}

The compiler set the parameter to itself, causing a no-op. There was
no warning! (C# compiler needs to get a lot better at emitting
warnings IMNSHO). I think this is one of the reasons people use this
naming convention:

fields: m_FIELDNAME or other unique type of name
Parameters: camelCase
Properties: ProperCase

It guarantees that all 3 types of name are unique.

 

[Kevin Spencer]

As everyone else has mentioned, consistency is the key. The most important
thing to keep in mind is the readability of the code, which includes naming
conventions as well as indentation, spacing, etc.

Because C# is case-sensitive, we use Pascal Case for public fields and
properties, Pascal Case preceded by underscore for private fields and
properties, and camel case for variables within methods and method
parameters. This way we can use the same identifier in 3 different ways
within the same class. Example:

private int _Count;
public int Count { get { return GetCount(_Count); } set {
SetCount(value); } }

private int GetCount(int count)
{
return count + 1;
}

private void SetCount(int count)
{
_Count = count - 1;
}

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Who is Mighty Abbott? A twin-turret scalawag.

 

[Marc Gravell]

For ref, in 2.0 this is caught as a warning:

Warning 1 Assignment made to same variable; did you mean to assign something
else? C:\{path to file}\Program.cs 10 9 WindowsApplication1

Marc

 

[Kürsat]

I use Visual Studio 2005 and a warning is generated in this case.

 

[Kürsat]

Serious software teams almost always have standards about naming, design,
deployment... So we, developers, are generally not free to choose our
favorite naming convension.

 

[Stoitcho Goutsev \(100\)]

Do whatever will make the code clearer for you and the other memebers on the
team (current and future). As long as these are private fields I don't think
you should follow any standard rules.

 

[Phil]

I use Visual Studio 2005 and a warning is generated in this case.

Aha thanks...probably my mistake then, I must have missed it. Have to
turn on "treat warnings as errors" I guess.

 

[Dylan Parry]

However, one of the newer guys has informed us that this is bad
practice.

Surely the new guy should learn to accept that your team has standards
that you all adhere to? I wouldn't have thought it was his place to
criticise your team's coding style

Is this good, bad or no big deal?

As others have said, it's no big deal, as long as you're consistent and
all happy with it.

 

[Marc Gravell]

I wouldn't have thought it was his place to

criticise your team's coding style

Personally, I welcome people /questioning/ things (although an outright
attack might be out of place); as long as the question is reasonably
intelligent (which this is), then it is a good opportunity to ensure that
you are doing things *for a reason* (ideally, a sensible and documented
one), rather than just habbit.

But I also accept that where there /is/ a valid reason, the new guy should
live with it ;-p
And consistency with the parallel code-base is a pretty good reason.

Marc

 

[PromisedOyster]

Thanks Kevin

Our standard is the same as yours except that we use camelCase prefixed
with an underscore for private fields, ie private int _count; Also,
layout, indentation etc is consistent so that's not an issue.

I was just wanting to make sure that we were not out of step with
industry practice regarding private variable naming.