this is basically a very nerdy question, but it influences the usability of one’s API. Let me get to the point…
Basically, the regular C# naming conventions don’t apply to Unity, due to its mixed languages. For example, while in C# you would name a property with PascalCase (MyProperty), inside Unity’s engine properties are named in camelCase (myProperty).
I’d be curious to know how you approach this “issue”. Do you use the regular C# naming conventions you were used to, or do you adapt them specifically to Unity (so that, especially when you create Unity extensions, users don’t get confused with different conventions)?
I personally use the Resharper naming conventions as resharper will ensure that they are followed by visually pointing it out and offering powerfull refactoring to reestablish them.
Those are PascalCase for public / protected properties and fields and _camelCase for private properties and fields and PascalCase for all methods independent if private, public, static, …
But one could naturally use whatever they want, I simply hate the Action Script naming mess with ‘starting all in lower case’ but UT likely used it for exactly this reason as UnityScript (missnamed as javascript) is targeted at exactly this userbase and it used to be the primary / only really supported language (unity prior unity 3.0 had no documentation for C#)
I follow the widespread C# naming conventions too - it’s consistent with Resharper and the Microsoft APIs. I ignore Unity’s conventions - you can’t avoid them, you just have to live with them. The most significant is indeed that Unity properties are camelCase - e.g. gameObject, transform, networkView, transform.position, transform.localScale, … Other than that, I think Unity’s conventions are OK. Things seem to appear fine in the inspector regardless of which convention you use, so that’s not an issue either.
Pretty much all UnityEngine/Editor properties are camelCase, dreamora. E.g., all the member properties on this page: Unity - Scripting API: Light
It’d be nice if Unity Tech could consider this for a future (albeit low-priority) update. It makes codebases feel extremely clumsy when you’re combining UnityEngine and the .NET BCL.
I must admit I just assumed enabled and its ilk were members not properties given their case (and assumed this was the correct way to distinguish… I come from a java background so capitalising methods is strange enough for me!)
I don’t think Unity will be able to change its naming conventions (which I suppose derive mostly from JavaScript), due to its combined languages . Though indeed, being able to recognize a property more easily (either by having it PascalCase, or by having Unity docs specify that it’s a property) is very important, since fields are more performant. I see a lot of people using myGameObject.transform a lot, thinking they’re just calling a field which stores a reference (while instead they’re calling a property that calls myGameObject.GetComponent).
About Resharper, I use it too, but I think it’s easily abused. And even when used, you can still customize it, since its naming conventions are not necessarily the right ones With Unity, initially I was using a more Unity-like naming convention (my tween engine, HOTween, actually uses it), but now I decided to move to a more C# like one.
P.S. @dreamora: as stringbot mentioned, almost everything that is mentioned as “variable” in Unity docs is indeed a property (like transform).
I just follow the Unity conventions because I spend all day doing C++ I honestly didn’t know any better.
The code for UIToolkit uses camel case for functions as well, which I kind of found refreshing coming from C++ but does look a bit messy mixed with other code.
Ehe, I know what you mean. I came from ActionScript, where almost everything is camelCase or SCREAMING_CAPS. But I have to admit that now I think C# is much more readable.
I don’t know of any C# naming conventions that treat properties differently to fields. The distinction with PascalCase and _underscoredCamelCase in the Microsoft and Resharper schemes is more to do with accessibility - public vs private.
You’re totally right, my brain is exploding today and I got confused :B For that, it would be just important for Unity’s docs to mention if something is a property or not.
Personally, for private fields I use an underscore prefix with camelCase, and simple camelCase for protected/internal ones (though this is more for internal readability than public API).
I use camelCase for variables and AlwaysFirstUpper for methods. Properties are no different from variables, so they are camelCase. If a public var (maxNumAllowed) becomes a property (ie get/set), then I add an ‘m_’ to the private internal variable, like this ‘m_maxNumAllowed’.
Naming conventions will not make/break your plugin. If your plugin rocks, it rocks with any style.
@Imbarns: interesting. You mean you use camelCase for methods with no arguments?
@Gigiwoo: ehe true. But if a plugin that rocks also has style, it rocks even more
Personally, I also used to prefix arguments with a “p_” (p_someArgument). Way better readability while developing, but after many years I realized it’s a pain to maintain (and annoying for users). Now I just use camelCase for those.
Have not read through the thread, just replying directly tothe OP:
I always use camelCase for variables and functions, I reserve PascalCase for constants (or variables I will treat as constants.)
I will also usually ad an underscore, “m_” or “my” prefix to all member variables that wont be directly accessible from outside the class (is mutable the PC term for those…? not sure…)
Classes and custom types (if it applies to the language) I always name in PascalCase.
I do this in any language, I don’t care what others do in different languages, I just want to keep my own coding consistent in every language.
There is one huge exception to this approach: SQL.
In SQL I demand PascalCase and to encapsulate all objects (fields,tables, schemas,etc) in [Brackets].
I’m also extremely picky (in every language) with indentation and symetry. I will go out of my way to format declaration/assignment blocks so the variable declarations equal signs are all vertically aligned. Example:
private string myString = 'string';
private int myInt = 1;
public static float myFloat = 1.0f;
(and darn it’s hard to simulate in the forum post)
Ouch… aligning anything other than the first character of the line is evil!
lzitmee, at my previous job we experimented, in C++, with prefixing function argument names with ‘z’, i.e. ‘zBlendFactor’. It was useful to be able to see, on a line of code, whether it was referring to an argument or a local variable. But when you’re working in languages that support named arguments, you really want the argument names to be undecorated.
