Why do we use _ in variable names?

Question

I have seen variables like _ image and was wondering what _ meant?

Solution 1

It doesn't mean anything. It is rather a common naming convention for private member variables to keep them separated from methods and public properties. For example:

class Foo
{
   private int _counter;

   public int GetCounter()
   {
      return _counter;
   }

   public int SetCounter(int counter)
   {
      _counter = counter;
   }
}

Solution 2

In most languages _ is the only character allowed in variable names besides letters and numbers. Here are some common use cases:

• Separating words: some_variable
• Private variables start with underscores: _private
• Adding at the end to distinguish from a built-in name: filter_ (since filter is a built-in function)
• By itself as an unused variable during looping: [0 for _ in range(n)]

Note that some people really don't like that last use case.

Solution 3

Some people use it to indicate that they are variables rather than (say) method names. Or to make it obvious that they're instance variables rather than local variables. Sometimes you see extra prefixes, e.g.

private int m_age; // Member (instance) variable
private static int g_maxAge; // Global (static) variable

It's just a convention. I was going to say "there's nothing magic about _" but that's not quite true - in some languages a double underscore is reserved for "special" uses. (The exact usage depends on the language of course.)

EDIT: Example of the double underscore rule as it applies to C#. From the C# 4 spec, section 2.4.2:

Identifiers containing two consecutive underscore characters (U+005F) are reserved for use by the implementation. For example, an implementation might provide extended keywords that begin with two underscores.

Solution 4

Usually it separates class fields from the variables. To avoid using this in code constructions.

class MyClass {

 private int _myIntField;


    private void setMyIntField(int value2Set) {
     _myIntField = value2Set;
    }

}

Solution 5

Well Underscore character(_) begin with your variable name is discouraged but it is legal and some people use it to identify as an private variable and some for naming it in caching variable. Go through with this link too.

View more solutions

Comments

[A. Go]

I'm not sure other language, but in C#, the _naming is legacy thing (due to limitation and broken stuff of old system / framework). Please stop saying it is a Convention, it Isn't. It's a lie, an excuse for people to write ugly code. (It may have some use case, but rarely, so please don't do that.) Also, stop lying it is a convention or thing.

[Davy8]

By "some languages" you mean Python right? Or are there other languages that do that as well?

[Jon Skeet]

@Davy8: Actually I was thinking of C, C++ and C#. (I'm not sure about the first two, but I'm reasonably confident. I'm sure about C#.)

[Ben Voigt]

In C and C++, one leading underscore + capital letter is also reserved. Use of leading underscores in user code is discouraged. (In general, having two identical-except-for-underscore names is discouraged, because the two are easily confused.)

[eykanal]

I've seen many instances where _varname indicates a private variable.

[A. Go]

No, it isn't convention. In C# the _ variable style is a legacy thing (can't exactly remember where it came from, some old reference book do mention.) It is even use in view like _ abc.cshtml, but the thing is, there was some issue with old framework / system, nowadays the newer dot Net doesn't require any stupid thing like that, it is bring forward from legacy broken stuff. The only use case for _variable is when you want to avoid name collision between the C# get set accessor with your private member. But still, you rarely use that unless your get set accessor has validation logic.

[A. Go]

Nope, it doesn't need this . to know it is private variable. It was legacy thing bring into C# but modern dot Net doesn't enforce nor require those nonsense. It is legacy broken thing, and it is another way for people to write ugly code with unsound justification for it. (It may be useful in some case, but rarely, and please stop that.) Please pardon young programmers from subsequent generations.