this. or underscore prefix in C#?

I’ve been programming in C# for 3 years and I’ve seen it done both ways. Normally I would say it’s just a matter of opinion. But MonoBehaviour throws mud in the water by exposing lots of public fields in camelCase. So I’m wondering if one convention is better than the other for Unity.

Consider the following 2 code samples:

_convention = "Underscore prefix ";         // Assign to a private field
string myText = _codingConvention + name;   // name looks like a local variable
_transform = transform;                     // No name collision when caching the transform
this.convention = "This dot prefix";                 // Assign to a private field
string myText = this.codingConvention + this.name;   // Longer but more clear
this.cachedTransform = this.transform;               // To avoid a name collision

Which do you prefer in your own code?

Unity 5 makes caching transforms somewhat meaningless.

You can mark fields with the [SerializeField] attribute to expose them to the editor but not elsewhere if you’re unhappy with all these public fields.

3 Likes

Thanks @Glader . [SerializeField] is great for controlling what shows up in the inspector (and what gets serialized). We could probably do a whole thread on the virtues of hiding public fields, and why Unity decided not to follow that advice.

But we still have to deal with public fields like transform, gameObject, name, renderer, etc whenever we extend MonoBehaviour. Check my original post and you’ll see I’m actually talking about the variable naming convention. Do you use this.myVariable or _myVariable as a general rule?

Would you care to elaborate?
I am in the process of porting some code to Unity 5 and I’d like to know what you’re referring to. I cache various components that are used often. Partly because it was advised in Unity 4 and partly because I don’t like writing ‘x.GetComponent().blah’ every damn time.

OnTopic:
I prefer the this-prefix. What’s far more important than which prefix you use, is making sure that you always use the same => Consistency.

I’m not so sure this is just a matter of preference as a variable with a preceding underscore does not necessarily signify that it is a private field, whereas an object referenced with “this” keyword will always be… if that makes any sense.

I used to use underscores and this.whatever in Flash AS 2 & 3. I don’t in Unity. I Just CamelCase with a lowerCase letter starting in Unity. i like my vars public so i can watch them all. This is my form of debugging to some degree…for watching things that do not throw errors but i need to/want to/like to track without the console spamming per frame.

i prefer and use the first one, underscores and ‘this’ only when needed
resharper recommends _convention for private non-const

As the OP I might as well throw in my opinion.

I have used both ways in Unity, and right now I prefer using ‘this’. Underscore is a nice way to do things when your entire code base makes all public members PascalCase. But with unity throwing in camelCase, I think the ‘this’ prefix is more clear. The only caveat I’ve seen so far is you can’t have any private members that mirror public MonoBehaviour properties with the same name, like in the _transform vs. cachedTransform example.

BTW: @hippocoder , I’m looking forward to Unity 5!

This claim in incorrect. Usage of this.x indicates that x is an instance member. It could be public, private, field or method.

1 Like

Well…it’s still faster to cache transform in Unity 5. It’s a little faster to use transform without caching in Unity 5 compared to Unity 4, but it’s not a huge difference. However, in the large majority of cases, it won’t actually make any difference either way anyway, unless you’re accessing transform really a lot (once a frame is not a lot).

–Eric

Many of the camelCase inherited members in MonoBehaviour are going away in Unity 5, but it’s still true that in general across the API we use camelCase for our public properties.

Personally, I use _underscore because that’s what Resharper encourages me to do, and I believe it matches the style used by the .NET framework itself. But it’s not that big a deal; I could just as easily configure Resharper to enforce a different style (and should do, if I decided a different style were warranted).

Neither of your options make sense to me, for Unity scripting.
http://forum.unity3d.com/threads/using-properties-to-be-or-not-to-be-advice-needed.282770/#post-1866473

That is incorrect; you just need to hide MonoBehaviour’s members by using the new keyword.

new Transform transform; Transform Transform {
    get {return transform ?? (transform = base.transform);}
}
3 Likes

Neither, underscores are ugly and typing “this.” is pretty pointless. I think camelCase makes the most sense since it looks better, and most variables SHOULD be private on any particular class IMO. Therefore would it not make more sense to distinguish public variable names, since they are against the norm…

2 Likes

@Jessy , that’s a really neat trick! I’d never thought about hiding base.transform.

Do you subclass MonoBehaviour with your own property overrides?

Correct me if I’m wrong, but Unity programmers internally uses the “m_” prefix, e.g. m_Transform for private members.

Personally I find some variation of _ clearer than this.

No. If C# provides a manageable way to do that, I don’t know of it.

Fun fact: use “m_varName” as a public variable name (for some reason), and the inspector will read “VarName”.

–Eric

1 Like

Why would you make it public when you can [SerializeField]?

That’s really not relevant; the effect is the same. The point is what you see in the inspector.

–Eric