When to prefix a variable with underscore?

Question

I am new to C# and .NET.   When should a variable be prefixed with an underscore?  I see it used but I don't know the rule.

Thanks,   Neal

---

Retired _ Active

Answer 1

 Don't do it to avoid a number of problems. It is a Microsoft prerogative to use underscore. Never start any fields, properties, methods or constants with underscore. It is a recommended MS style.

---

AlexB

Answer 2

It's a way of indicating variable scope. Not everyone uses it and it's one of those code religion topics :) Sometimes you'll see it used for private variables, such as _something, then a property called Something will reference the variable. Others use a lowercase variation of their property, again similar to a myValue variable, then the property is MyValue and returns myValue. Here's an example of the 2:

public class Person

{

private string _firstName;

public string FirstName

{

get { return _firstName; }

set { _firstName = value; }

}

}

// no underscores

public class Person

{

private string firstName;

public string FirstName

{

get { return firstName; }

set { firstName = value; }

}

}

There are arguments for and against about it enhancing readability and even the order of variables in the members dropdown list or the locals debug window etc. (underscores sit at the top of the list).

For more on this subject take a look at these links:

• Brad Abram's Internal Coding Guidelines (look at section 2.6 Naming Conventions)
• Article discussing variable scope:  http://blogs.msdn.com/rickhos/archive/2004/07/09/178816.aspx
• Peter Ritchie's post on class member prefixing
• Hungarian Notation - look under the examples section.

---

Document my code? Why do you think it's called "code"?

Answer 3

I use underscore for any property' private variable. I have a reason, because I use lower letter rule for any method parameter or any constructor parameter. Here is simple example:

public class Complex
{
     private double _X;
     private double _Y;

     public double X
     {
           get;
           set;
     }

     public double Y
     {
           get;
           set;
     }

     public Complex(double x, double y)
     {
           _X = x;
           _Y = y;
     }
}

So if I used lower letter for private property variables in my constructor i need to have this code:
this.x = x;
this.y = y;

It's not a problem that I need to type x but you can make mistake very easy if you forget to put this clause if you have a large chunk of code. By the way some add-ins like ReSharper will warn you that you have same name of private variable and method or constructor parameter.

---

MCDBA, MCSD, MCITP http://sharpsource.blogspot.com/

Answer 4

Leading underscores is a C/C++ convention.  Pretty much required to avoid problems with macros and user symbol names colliding with compiler vendor symbol names.  Namespaces were a late addition to the C++ language standard and still not available in 'C'.  There are not a lot of good reasons to use it in C#.  No macros, consistent namespace usage, separate symbol tables for type and variable names.  Even a naming collision with an argument and a field is easily solved:

  public class Sample {
    private int field;
    public Sample(int field) {
      this.field = field;
    }
  }

If you want to use it to indicate scope then that's okay.  Some of the MSFT developers that wrote code for the internal framework classes used it.  Not many of them though.

---

Hans Passant.

Answer 5

 I use "postscore" to indicate scope as the other posters mentioned. I strictly avoid it. As nobugz said, it is mostly in C++ realm.

private static System.Security.SecureString myString_ = null;

public static System.Security.SecureString myString

{

get { return myString_; }

set { myString_ = value; }

}

---

AlexB

Answer 6

Personally, I think this is too “old school” in thought.

I mean, if you really want to say it’s a field, just do this…

field_X
field_Person

or

X_field
Person_field

Then there wouldn’t be all these “What’s this underscore mean?” posts.

And it also makes it look real ugly like some sort of mis-formatted text.

---

rasmasyean

Answer 7

My 2 cents:

private void SomeMethod()
{
    someInt = 5;
}

Is someInt a class variable as in:

private int someInt;

or an internal property variable as in:

private int _someInt;
protected int someInt
{
   get { return _someInt; }
   set
   {
      someInt = value;

      // insert logic that should always be performed
      // whenever the integer is modified ... such as:
      //
      // RaisePropertyChanged("SomeInt");
   }
}

SomeMethod doesn't care (as it shouldn't care).

The beautiful things about an internal property variable is:

1) no matter how someInt is being accessed (a public SomeInt property which gets / sets someInt, local to the class, or even from a parent class via the protected someInt), I KNOW the code will be filtered to the internal property someInt and therefore I KNOW that changing the value will cause the logic associated with the change to be performed. Furthermore, the business logic that is changing someInt doesn't need to know the internal workings of my class and therefore setting someInt becomes a black-box scenario.

2) It provides the same safety mechanisms between private _someInt and protected someInt (with regards to parent classes) as does public SomeInt { get ... set ...} and internal someInt does to instantiators of my class.

3) I can start off with private int someInt; and if I need some logic to occur when someInt is modified, I can refactor it to an internal property without chaning ANY other code. If i started with:

private int _someInt;
private void SomeMehtod()
{
   _someInt = 5;
}

... and I refactored to:

private int _someInt;
protected int someInt
{ get ... set ... }

then i would have to REMEMBER to refactor
SomeMethod()
{
   _someInt = 5;
}

to

private int SomeMethod()
{
   someInt = 5;
}

As far as the issue whereby you need to use 'this' to distinguish between class variables and local method variables, I think using 'this' is more readable than an underscore (subjective I know), and I have never accidentally NOT used 'this' when I should have.

And thats my 2 cents.

Answer 8

@xjonx The general practice is for properties to start with a capital letter, and for variables to start with a lower case letter, so that's how one distinguishes between a field and a property.

Answer 9

The general practice is for PUBLIC properties to start with a capital letter. I might have the following:

private int _myInt;

protected int myInt

{

     get { return _myInt; }

     set

     {

          _myInt = value;

          RaisePropertyChanged("MyInt"); <- or some other business logic

     }

}

public int MyInt

{

     get { return myInt; }

     set { myInt = value; }

}

private void SomeMethod(int newInt)

{

     myInt = newInt;

}

No matter how the integer is changed, Public MyInt, parent class with myInt, or internal such as MyMethod, RaisePropertyChanged will always be called.

Whereby most of the arguments for underscore or not is specifically aimed at distinguishing between class variables and method variables, the above structure is designed so SomeMethod doesn't KNOW if it's accessing a property or field ... because it shouldn't care.

If your point is limited to public properties, then I completely agree with you. I would never have a public lowercase property.

Answer 10

"The general practice is for PUBLIC properties to start with a capital letter. I might have the following:"

No, the general practice is for ALL properties to start with a capital letter.  Your own conventions might be nice for you, but they won't be shared by others, so when other people work with your code, or when you work with the code of other people, it will cause problems.

As for that last example, there's no real point in a protected property with a backing field if the public property is just wrapping the protected property which just wraps the field.  Save the intermediaries and have the public property just wrap the private field (or protected field if the class requires it) and put your property changed logic in the public setter.

Answer 11

Conventions are created by debating design patterns and the community decides what is
better. At one point, because C / C++ programmers WERE the community,
underscores was the "general practice".<o:p></o:p>

If it was true that there is no reason to wrap a variable with a property if the only
thing the wrapper was going to do was Set and Get the variable, then general practice
would accept public class variables. After all, a public class variable would, “save
the intermediaries”, right?<o:p></o:p>

Since the point of the design structure is to keep developers from HAVING to know what to
access (Capital or Lowercase value), but instead always access the lowercase
from within the class or parent class, then there is no problem. The point IS
that the developer of SomeMethod always treats it like a class variable and can
concentrate entirely on the business logic of SomeMethod.

In this way, I am able to funnel all access to the value to a single point of code and
introduce value-has-changed business logic without any other developer even
knowing it, not alone having to care about it. As a matter of fact, i could start off with a field and later refactor it to a property with field backing and other developers would have no need to know.

And so, in my humble opinion, the structure is better. If the community rejects it, ok,
but my logic is sound, despite it being (currently and maybe forever) not
general practice.

Answer 12

"Conventions are created by debating design patterns and the community decides what is better. At one point, because C / C++ programmers WERE the community, underscores was the 'general practice'"

It's my understanding that the underscore prefix originated in Basic/Visual basic since it's case insensitive and so capitalizing/not capitalizing the first letter is not a valid way of differentiating the scope/type of an identifier.

"If it was true that there is no reason to wrap a variable with a property if the only thing the wrapper was going to do was Set and Get the variable, then general practice would accept public class variables. After all, a public class variable would, “save the intermediaries”, right?"

Except that's not what I said.  You're wrapping a variable in TWO properties, thus you have two intermediaries when you only need one.  Wrapping a SINGLE field in a property is perfectly acceptable and generally good practice.

"In this way, I am able to funnel all access to the value to a single point of code and introduce value-has-changed business logic without any other developer even knowing it, not alone having to care about it."

And this is easily achieved by using a single property, optionally with a backing field.  If you use a backing field for the property you still should NOT use it within the class itself; you should use the property to access the data, so that you can introduce changes to how that data is accessed.  The backing field of a property should only be accessed if there is a compelling reason for the property to bypass whatever additional functionality the property provided.

"As a matter of fact, i could start off with a field and later refactor it to a property with field backing and other developers would have no need to know."

That's not strictly true, there are differences between the two for which it may be important to know about this change; for example, you can't use a property as a ref or out parameter.  There are also issues if you happen to be using a mutable struct as the type of the field/property.

Additionally, through the use of refactor/rename in visual studio, you can change the code everywhere it's referenced inside the class from a field to a property easily enough.  Rename the field to have a capital letter (with refactor/rename), add the property to be the same name, then rename the field back to a lower case name (without refactor/rename) and viola.  You just changed all references to the backing field to be that of the public property.

"And so, in my humble opinion, the structure is better. If the community rejects it, ok, but my logic is sound, despite it being (currently and maybe forever) not general practice."

The problems with using a naming style that differs from rather strongly established norms are significantly greater than the (rather small) potential advantages of your naming convention.

Answer 13

“It's my understanding that the underscore prefix originated  …”

I thought it came from C /C++ because C still doesn’t and C++ didn’t for a while have classes. I’m not sure enough or really care enough about it to quibble though.

“Except that's not what I said. You're wrapping a variable in TWO properties, thus you have two intermediaries when you only need one. Wrapping a SINGLE field in a property is perfectly acceptable and generally good practice.”

I know what you said. I read it very carefully because I am trying to process and address what you’re saying without jumping to conclusions. There IS a reason to have TWO properties. I laid it out. It’s so the developer of SomeMethod doesn’t HAVE to care. I’m bolding that statement because you’ve missed it several times. You keep arguing that everything TWO properties can accomplish PROGRAMMATICALLY can be accomplished with one property. This is true. Without a doubt, programmatically, there is NO reason to use the structure I presented. BUT, two properties allows that thing called ‘myInt’ to be my ONLY concern and then I don’t have to have TWO thing to worry about ‘myInt’ and ‘MyInt’ (mostly, see next issue).

“That's not strictly true, there are differences between the two for which it may be important to know about this change; for example, you can't use a property as a ref or out parameter. There are also issues if you happen to be using a mutable struct as the type of the field/property.”

I completely agree with this statement. There are no absolutes. Exceptions such as what you point out in the above statement would require that the developer use the private field and then somehow handle the code that otherwise be executed in the property’s setter. This is true even if you only had ONE property with business logic in the public properties setter. But what your argument boils down to is; because of those situations where it does matter, the developer should ALWAYS be forced to have to be aware of the difference, not just when it’s important, which he would have to be aware of the difference regardless of ONE or TWO properties anyway.

 

“The problems with using a naming style that differs from rather strongly established norms are significantly greater than the (rather small) potential advantages of your naming convention “

We will have to agree to disagree on the “rather small” “potential” advantages vs. the “problems” that what I presented would incur. I think what I presented does exactly what many paradigms try to do, remove unnecessary details of the back end from what should be of concern in the present. But some of your points are valid, without a doubt.

Thank you for a civil the debate.

Answer 14

"It’s so the developer of SomeMethod doesn’t HAVE to care."

But they should care.  You don't want to silently change a private int field to a private accessor, change the name of the backing field, and just let the fact that the new property has the same name as the old deleted/renamed result in code accessing what you logically consider the same data.  This will result in problems, in certain circumstances, when doing this.  

It is better to make it clear to the reader whether some piece of code is referencing a property or a field since they are actually quite different (one is a storage location, another is the result of a method in disguise).  

"allows that thing called ‘myInt’ to be my ONLY concern and then I don’t have to have TWO thing to worry about ‘myInt’ and ‘MyInt’ (mostly, see next issue)."

But it should be a concern, because they're not identical.  Pretending that two similar but different things are identical WILL cause problems when you eventually run into those places for which they are different.

"I completely agree with this statement. There are no absolutes. Exceptions such as what you point out in the above statement would require that the developer use the private field and then somehow handle the code that otherwise be executed in the property’s setter. This is true even if you only had ONE property with business logic in the public properties setter. But what your argument boils down to is; because of those situations where it does matter, the developer should ALWAYS be forced to have to be aware of the difference, not just when it’s important, which he would have to be aware of the difference regardless of ONE or TWO properties anyway."

It's a point of confusion for the reader.  You save a few seconds in refactoring your code in exchange for never being sure whether a particular identifier is a property or a field.  There is a difference, and that difference should be communicated to the reader.  

Consider the case where you have a backing field in addition to a public property.  It's rather helpful for the reader to know that:

this.Value = 1;

Could be doing more than just setting an int; it could be doing validation of input, security checks, logging, whatever.  It could also throw an exception whereas if Value was an int field rather than a property this line could never throw an exception.  If it's not clear to the reader that they're accessing a property rather than a field they may simply skip over this line when looking for the cause of an error/exception.

"I think what I presented does exactly what many paradigms try to do, remove unnecessary details of the back end from what should be of concern in the present."

It is not an unnecessary detail that some identifier is a property vs a field.  There are a significant number of differences in the behavior between them.  The fact that it's a somewhat-less-often-to-come-up detail makes it all the more important that you be able to tell them apart.  For example, a straight method and a field are so different that they just don't get mixed up despite fairly similar naming conventions.  When things are kinda the same but not exactly the same and you treat them as if they were exactly the same it leads to very hard to track down bugs.

And what's the advantage?  You save a few seconds in refactoring your code which you will do really rather rarely, and never more than once per variable.  Additionally if you find yourself constantly turning fields into properties you can just get in the habit of making everything a property right from the start.  Auto-generated properties make it very little extra code, and then you'll never need to refactor anything.

"Thank you for a civil the debate."

You're welcome.

Answer 15

Thanks for the explanation for the variable pre-fix. My professor is a "purist" and I was wondering if it was a pointer, laughs.

Answer 16

I am new to C# and .NET.   When should a variable be prefixed with an underscore?  I see it used but I don't know the rule.

Thanks,   Neal

---

Retired _ Active

There are no rules, just guidelines... and don't let anyone with a loud opinion on the matter tell you otherwise. The language has rules, the way you write the code is "guided" by one of two things.

1. If the code is for you only, then you write it in a way you understand it.

2. If the code is part of a collaboration, then it is preferred if you write it in a way that can be understood by all.

All it does, is differentiate scope levels. For instance, I write game software, so I might have an entity that has a Position property. That entity might have several associated entities that also have their own Position.

So within a function where you have passed in another entity, pulling its Position into a Variable can't be done by using Position, because that's your existing Property for your main entity. So using _position is a way of referring to that associated entity's Position, without conflicting with your main class Property of the same name.

All you are doing, is giving yourself a way to identify scope levels and if that means that _position works for you, or localPosition, or position, or myPosition, or entityPosition, then that's what you use.

Don't get sidetracked by opinionated know-it-alls, because when you start looking into the quality of software written by them, it's often well below the quality that their opinion would make you believe they are capable of.  Microsoft software being a prime example of that. Lots of "experts" and "authorities" on the subject, churning out mediocre software. Clever coders don't guarantee great software, they just guarantee clever code... big difference.

---

Worms Forts 10/10, MotoGP3 10/10, Worms 10/10, Rogue Trooper 10/10 - Thank you Total Mobile :D