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.

"PromisedOyster " <Pr************ @hotmail.comwro te in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

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?

[Jon Skeet [C# MVP]]

PromisedOyster wrote:

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
ja***@removethi s.dystopia.fi
http://www.saunalahti.fi/janij/

[Phil]

On Fri, 4 Aug 2006 14:34:45 +0300, "Jani Järvinen [MVP]"
<ja***@removeth is.dystopia.fiw rote:

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

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

"PromisedOyster " <Pr************ @hotmail.comwro te in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

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 use Visual Studio 2005 and a warning is generated in this case.

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

[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.c s 10 9 WindowsApplicat ion1

Marc

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

"PromisedOyster " <Pr************ @hotmail.comwro te in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

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?

[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.
--
Stoitcho Goutsev (100)

"PromisedOyster " <Pr************ @hotmail.comwro te in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

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?