variables prefaced with underscore "_"

Unity Engine
1

I don’t remember in what condition one uses underscore to qualify a variable like as follow:
if (_skin == null)

{

_skin = GUIUtility.GetBuiltinSkin(0);

}
I could not find a reference to the underscore in the documentation or ressources but I am sure it has to be somewhere.
Can somebody help me with that
thanks

2

The underscore does not have any effect. It’s just a symbol that is part of the name. Programmers sometimes use a starting underscore to indicate something about the variable (what it is they want to communicate depends on the programmer). This also means that only the coder of that fragment can tell you why he or she decided to name the variable _skin.

3

Underscore has no behavioural changes whatsoever. It’s just another valid character you can use in a variable name. Usually people prefix their variables with underscores to denote some kind of temporary and/or private and/or typically-inaccessible value and/or whatever.

EDIT: DAMN YOU tomvds! Foiled again!

1 Like
4

My short experience of ActionScript 3 lead me to read code written in…ActionScript 2 (whose variable often used _ as a prefix).

But I never knew why :slight_smile:

…noone is gonna laugh ? :x I’d better run before I sblam!

5

The underscore is commonly used to denote member variables or non-temporary variables. Some other coding conventions, e.g. googles’ coding guidelines, place the underscore at the end because some of the more esoteric compilers out there can’t process leading underscores in variable names but the intention is the same.

1 Like
6

Actually that’s not quite true. A public variable called “_foo” and a public variable called “foo” will both show up in the inspector as “Foo”. Also, a variable called “m_foo” will also show up as “Foo”, though no other letter prefixes have that effect.

–Eric

1 Like
7

In C/C++, end users are not supposed to use variables beginning with an underscore, they are reserved for the compiler, and OS. This helps to avoid conflicts between user-defined variables and those needed to implement the language and core libraries. You’ll see _varname alot in system code.

8

Oh lord.

Oh why?

I just did a test with that:

public class TestScript : MonoBehaviour 
{
    public int m_Foo;
    public int _Foo;
    public int Foo;

    public void Start()
    {
        Debug.Log("m_Foo: " + m_Foo);
        Debug.Log("_Foo: " + _Foo);
        Debug.Log("Foo: " + Foo);
    }
}

And in the inspector it showed up as:

You can assign values, and they’re assigned properly in the order they’re declared. But seriously? Is there a legitimate reason behind this or is that a “usability” feature?

EDIT: Perhaps one possible reason was if you designed your class like this:

public class TestScript : MonoBehaviour 
{
    public int m_Foo;
    public int Foo
    {
        get
        {
            return this.m_Foo;
        }
        set
        {
            this.m_Foo = value;
        }
    }
}

This way in the editor, it’s like the user is reading/writing to a nicely named “Foo” (since the editor doesn’t pick up on properties), and in your code you can access it through the getter setter on a nicely named “Foo” as well (and consciously ignore the m_Foo field). If this is the reason, I can see where they’re coming from, but I don’t agree with it.

To be honest, I’d rather the editor pick up on public properties (instead of fields) and only those marked with a special attribute (or provide an attribute ignore properties, similar to how the XmlIgnoreAttribute works)

9

@HideInInspector?

–Eric

10

Ballin’!