Why does unity use m_PascalCase fields?

Scripting
1

I seriously cannot figure out where this came from or the sense behind it. Unity’s open source UI code is set up in this manner. There are also example in the documents setup in this manner.

for example here:

public class MyClass : MonoBehaviour {
    [FormerlySerializedAs("myValue")]
    private string m_MyValue;
    public string myValue
    {
        get { return m_MyValue; }
        set { m_MyValue = value; }
    }
}

I understand the camelCase property and the reason behind that. But if the property is camelCase why is the field m_PascalCase?

That isn’t even standard hungarian notation:

Standard hungarian notation in m_camelCase.

I could understand them using m_PascalCase if the property was PascalCase. But it isn’t, the property is camelCase, so how, where, why and what did they decide that m_PascalCase for the field was appropriate?

Just really curious to know.

2

So, you understand where the m_ hungarian notation came from? Right?

And you know where hungarian camel case came from, right?

How hard is it to believe some person, somewhere, decided to instead of have the first word lower case, they went with upper case.

I could have spawned merely from someone not know that the hungarian notation usually starts lower case.

I mean honestly, it’s not that weird. It was just someones taste. You want to ask Joe down in development why he did that? How about you ask him why he also like Fanta over Crush?

3

I just want to know if there is some like historical or logical or some other reason as to why someone would use m_PascalCase… it just seems like it came out of nowhere.

4

It came out of personal preference.

These naming standards aren’t some hard fast rule defined by some commanding order. It’s just what the individual programmer decides to do.

In the case of Unity, they prefer public facing variables to be came case, they follow ecma stanards with that (kind of makes sense since unityscript is javascript like).

As for private internal fields, since they aren’t publicly facing, it’s really to the programmers discreession. May it be hungarian pascal, or hungarian camel… well it’s literally just ONE letter being upper or lower. I highly doubt the lead developer really quibbles with their staff about which should or shouldn’t be used. They both result in readable code that does not conflict with other code (its private after all).

5

Wait you mean to tell me the reason Unity used camelCase properties was because they initially wanted it to conform with ECMA because it was assumed unityscript was to be primary? Thats kind of makes me wish the properties were PascalCase now.

6

UnityScript used to be dominant, not that long ago.

But if you go messing around in people’s privates expect to be disturbed from time to time.

But neither of those are actual answers. The real answer to most coding conventions can be summed up in one word. It’s best expressed in this video. If you want to skip to the explanation it starts at 0:50

http://youtu.be/kDtabTufxao

1 Like
7

Well now that UnityScript is defunct, could the Unity codebase be refactored to be a bit more in line with how microsoft specifies the use of C#?

I’ve been on a bender about this for like a year now. What is the best and most well thought out C# coding convention. I’m starting settle on, how Microsoft defined it and how ASP.net is written. Unity UI source code seems like some funky not too well planned, inconsistent mix.

8

Most companies I know have some sort of language specification document including conventions to uphold, so I would expect a lead developer to quibble about which should or should not be used.

That said, techmage, using m_PascalCasing is a valid use of Hungarian notation as also explained in the document you linked:

Now, personally I never use the m prefix, nor do I PascalCase private member fields, but I do use an ‘_’ underscore prefix to differentiate them from local variables and parameters, so I can understand why they use the m prefix.

9

Oh my God that would be the best thing. Imagine how many resources Unity could free up by not supporting a bad, proprietary language that’s only used by some Unity users? Sadly, it is not defunct. It’s just getting used less as time goes by and people realize that it’s a shit idea.

The important thing about coding conventions is to be consistent within projects. I’d not be supprised if the m_ style started out when Unity was three people in a basement, and has just stuck because it’s not a problem.

1 Like
10

Yes, but to an extent.

My point was that the difference between: “m_someVar” and “m_SomeVar” is so inconsequential that the lead probably doesn’t quibble over it. Especially since it’s a private member.