C# naming conventions for Unity

Hello,

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)?

 

Well i never new how to program at all before i used unity, and i only program in unity so i guess i use the unity ones

 

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: http://unity3d.com/support/documentation/ScriptReference/Light.html

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.

 

^^ What he said

 

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!)

EDIT: Which goes to show this is important

 

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).

 

Any Unity devs can comment on why Unity uses the naming conventions it uses?

 

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.

Gigi

 

Damn I thought PascalCase was for constructor functions. hehe

I do camelCase for vars and Uppercase for methods that take arguments.

 

@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:

Code (csharp):

1.  
2. private         string  myString    = 'string';
3. private         int     myInt       = 1;
4. public static   float   myFloat     = 1.0f;

(and darn it's hard to simulate in the forum post)

 

I just made up some conventions that felt right and use 'em

camelCase for Variables.

PascalCase for functions [and properties if I ever use em].

Never use '_' - personally I just find it ugly.

So far I've never really had any problems... so I haven't changed.

 

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.

 

The same conventions I feel comfortable using... I made that line bold because I 100% agree.

I will use all Upper case for constants

 

Aha, now that is exactly what I did! But one day I was massacred by a collaborator (stfx) because it's actually hard to maintain, and a pain in the ass I kind of miss aligning everything though. Readability was so much better.

Yup, I totally agree. I tried a simple "p" prefix for some time ("pMyArgument"), but than gave it up when I realized the issue with named arguments.

@KingCharizard: while I agree and use those conventions, I really can't go without the "_" prefix. I know it's ugly, and that's why I use it only for private variables and not for protected/internals (so that something like myObject._myVar will never happen), but it gives code an immediate readability - especially if you're just looking at something on github or without a serious editor helping you (only on my opinion, of course).

 

Yea I always have. In javascript it was fairly standard to use camelCase for everything but constructors like:

 

Crap, really?! I need to stop using .transform so much.


On topic - I follow Unity's standards of camelCase public fields and properties when I'm coding for Unity, but I feel dirty the whole time I'm doing it. But I feel schizophrenic when my fields use PascalCase and Unity's use camelCase. Either way it's kind of a pain.

 

To this date every environment I used seems to maintain very nicely as long as a fixed width font is used (seriously, who codes with variable width fonts????)

Working on an environment where everyone uses the same tools also helps a lot.

Mind you, I don’t do that for the entire code, I do it mostly for small isolated declaration blocks and assignment sections. Goal is precisely to keep related blocks of code with similar vertical layout. If the next 4 lines of code have a different purpose, they can be aligned independently (and have at least 2 blank lines in between!)

Right now, this very minute, I am working on re-formatting a few hundred very complex SQL functions (loaded with sub queries that themselves may have sub queries) that were not only “not indented” but apparently were just generated with a wizard. Seems no one has touched any of the views and everyone dreads doing any maintenance code due to the unreadable formatting.

 

I read that on the documentation, they warn you not to do many direct calls to things like gameObject.transform or gameObject.rigidbody.

Used to directly call gameObject.transform before, the change got me some nice performance boost.

After reading that I modified all my code to have one local myTransform variable I assign at Awake. If I need anything else, like rigidbody, material access, etc, I declare local myX variables for all of them and fill them at Awake.

 

True. The same is in ActionScript, but I tend to forget it

Kind of a pain it is

Sigh, again, exactly what I did until a couple months ago. The difficult maintainability that stfx made me notice was not due to variable width fonts, but to the fact that defining a new variable takes a little more time than the unaligned version. Also, when you insert a new longer variable, you might have to re-align all the group. But again, I seriously miss it (also because I used alignment for like the last 10 years). Reading you I'm thinking of possibly getting back to it

I do the same, though I fill the variables at Start, because in some case (can't remember the exact occasion) it happened that something wasn't "ready" to be stored at Awake.

 

It may take longer (in my opinion not too much longer) but it saves me a lot of time during debugging. I actually started doing over the years precisely because I noticed it was easier for me to find bugs by scanning through symmetrical code. Your millage may vary on that, though.

If you are trying to get the transforms or other component of other MonoBehavior objects, you may need to make sure the script execution is properly configured so the class that needs to access the other classes is always executed first. I have had a couple cases where I had to use Start, though, since I had a bit of cross-referencing (and slapped my hand for doing the cross referencing in the first place but was in a rush .)

And that says something about the previous point: I will take time to format in a rush because I know it will help me that much on debugging, even when I ignore some "proper programming practices."

BTW, I don't force others that work with me to do this indentation, but I will reformat their code if I am forced to debug it.

 

I kind of assumed Unity was just doing that for me. It seems like if they went through the trouble of making it a property, knowing you'd access it a lot, they'd keep a reference to it. Or maybe start with no reference but cache it the first time you call it rather than using GetComponent every time. Oh well, now I know!

 

I would point out that this is NOT the case [at least with monobehaviours anyhow].

http://forum.unity3d.com/threads/130365-CachedMB

 

Interesting; then what is the cause of the slowdown in the MonoBehavior version? Is it just that it has to cross the C#/C++ boundary every time?

Oh, and your code in CachedMB is pretty much what I assumed Unity was doing. It's kind of dumb that they're not. I guess it might save a small amount of memory not having the extra cached member variables if you're spawning a bunch of MonoBehaviors? Or they just didn't think about doing it.

 

I use very lengthy (and self-descriptive) names.
- camelCase for fields and PascalCase for methods.

But yeah, Unity needs to clarify all those "very important" things in their documentation. I know is not the case but I still see Unity documentation as a Doxygen generated class list with some small examples here and there. I think they've put some new technical writers to improve it, so hopefully we will see better documentation in the future.

 

@tatoforever: actually, Doxygen generated docs clearly show a distinction between properties and fields

@NPSF3000: Interesting - thanks for sharing

 

That's true yeah. ^^

 

I was intrigued by UT's doc setup too and asked them, it's an inhouse Doxygen-esque setup apparently.

Unity's also different to standard .NET insofar as you're actively encouraged to use fields rather than properties for inspector values, whilst .NET goes the other way and publicly shames you/burns your house down for exposing public fields; not that I'm hinting that I'd like properties standardised for inspector values or anything...

 

Nobody uses Apps Hungarian?

 

@stringbot: actually, even if .NET shuns public fields, they're slightly faster than properties. So for a game engine I believe it's the right choice. Anyway, Unity could've made a better Doxygen-esque setup

@SimonAlkemade: personally, I stopped using Hungarian when I moved from ActionScript to Unity and C#.

 

Over time I think I settled on a convention here a little automatically. I never made a conscious decision to follow this or that convention, it just happened that my code eventually started following a system.

Things public I name with FirstCharUpperCase, things private (or public but of lesser importance) I name with firstCharLowerCase. Enum items I name with ALL_CAPS_AND_UNDERSCORES.

Above all though, I try to make sure my variables, methods and props are always clearly named enough so as to be self-explanatory. That's not always easy, or even possible sometimes, but I try my best to keep things readable and understandable.

Cheers

 

I don't think it would be smart for an engine to start changing their naming conventions. The amount of hazzle for everyone using the engine would be considerable and the gain is more cosmetic than anything else.

This thread shows with all clarity that there are hundreds of opinions to naming conventions. And personally I wouldn't go calling one better than the other. As long as the engine naming stays consistent that's good enough for me.

Cheers,
UnLogick

 

I thinks it just wastes time and is in opposition to automatic code formatting which saves it.

 

I'm pretty sure that auto-properties are major candidates for inlining into direct access by the JIT compiler. Haven't noticed any difficulties in our own Mono/C# implementation in any case, and that exclusively uses properties.

 

I think the main case for using properties everywhere when you could use a simple field was "What if you need to change the implementation some day?", when people had nightmares about needing to go through their code manually and change the name of the field where accessed or where used internally. But the quality of today's automatic refactoring tools make that less of a big deal. I don't see the problem with using public fields, and if you at some point need to change it into a property instead because you want some custom get or set logic, then you can do it with a simple right-click command.

 

@stringbot: in theory yes. But I made quite a few test a short time ago. And auto-properties as well as properties were actually slower (just a little tiny bit slower). Will see if I have it again to post some result. Anyway, it's also true that, if you need to use reflection, reflecting properties is faster than reflecting fields

@alexzzzz (look! I got all the "z" correctly ): automatic code formatting sucks!!! Ahaha, no, seriously, it depends on the coder I suppose. Personally, I would never allow any software to auto-format my code.

 

I'm really hooked on auto-formatting:

Code (csharp):

1. using System.  Collections.         Generic;
2. using  System.Linq;
3.     using UnityEngine;
4.  
5. abstract public   class ScriptBase:
6.     MonoBehaviour
7. {
8. private Transform   cachedTransform;
9. public new Transform transform
10. {get{if (cachedTransform != null)
11.                 return cachedTransform;
12.            
13.  
14.             return cachedTransform = GetComponent<Transform>();
15.         }}
16.  
17. private
18. GameObject
19. cachedGameObject; public new GameObject gameObject
20.     {get            {
21.                         if (cachedGameObject == null)
22.                 cachedGameObject = base.gameObject;
23. return cachedGameObject;}} static public IEnumerable  <T> FindObjects <  T>(
24.     )where T:MonoBehaviour{
25. var instances =
26. FindObjectsOfType(typeof   (T)); return instances.Cast<T
27. >();}
28. public static T FindSingleInstance<T>() where T : MonoBehaviour
29. {return FindObjects<T>().Single();}}

Several keystrokes convert it into

Code (csharp):

1. using System.Collections.Generic;
2. using System.Linq;
3. using UnityEngine;
4.  
5. public abstract class ScriptBase : MonoBehaviour
6. {
7.     private Transform cachedTransform;
8.     public new Transform transform
9.     {
10.         get
11.         {
12.             if (cachedTransform != null)
13.             {
14.                 return cachedTransform;
15.             }
16.  
17.             return cachedTransform = GetComponent<Transform>();
18.         }
19.     }
20.  
21.     private GameObject cachedGameObject;
22.     public new GameObject gameObject
23.     {
24.         get
25.         {
26.             if (cachedGameObject == null)
27.             {
28.                 cachedGameObject = base.gameObject;
29.             }
30.             return cachedGameObject;
31.         }
32.     }
33.  
34.     public static IEnumerable<T> FindObjects<T>() where T : MonoBehaviour
35.     {
36.         var instances = FindObjectsOfType(typeof(T));
37.         return instances.Cast<T>();
38.     }
39.  
40.     public static T FindSingleInstance<T>() where T : MonoBehaviour
41.     {
42.         return FindObjects<T>().Single();
43.     }
44. }

 

If someone gave you that code, you shouldn't rely on auto-formatting, but on a good spiked mace to pulverize his brain That said, I have to admit that auto-formatting is definitely useful when copy-pasting code from Unity forums, since it gets copied sooo badly :/

 

ACK!!! JavityScript!!!! .... must.. not... look... must retain... sanity....

Seriously tough, for me, it takes nothing to format code and much longer to debug old code of unformated code, the few seconds it takes for me to format it are much more than worth it.

Mind you, I can type between 80 - 95 words per minute, inclining to the fastest speed if I'm just typing off my mind and not doing a duplicate typing test.

 

That was me how produced it
Actually I took a formatted source, made a little mess, and then launch auto-formatting.

 

UpperCase for methods and public fields.
_lowerCase for private fields.
lowerCase for scoped variables.

The general MSDN convention is pascal case (UpperCase) for everything, aside from parameters (parameterString, for example).

Feel free to skip the _ in private fields, really. Some people prefer to write mLowerCase instead, to indicate that it is a member variable. Some skip it, for the sake of readability. Some write Self.lowerCase, because the like verbose typing. It's a matter of preference. Just be consistent about it.

This doesn't conform entirely to the MSDN C# standard, but I find it useful considering my general absence of properties in Unity.

I'd use Resharper for any kind of regular C# project, though with regards to Unity, I'm not convinved.

 

I think it's unfortunate that Unity doesn't follow the .NET naming conventions with its properties but that's something I can't do much about. However, when using public member variables to expose settings to the editor, I follow an internal guideline that if I need access to those member variables from other scripts, I add a property (either only with get, or, if needed, also with set).

That way, I can have another guideline to never use camelCase-stuff from other classes. Something like:

Code (csharp):

1. public float someVariableForEditor;
2. public float SomeVariableForEditor {
3.     get { return someVariableForEditor; }
4. }

And then, if someone does something like

Code (csharp):

1. referenceToObjectOfThatOtherClass.someVariableForEditor

they'll be removed from the team immediately ;-) ... just kidding, but seriously, it should be:

Code (csharp):

1. referenceToObjectOfThatOtherClass.SomeVariableForEditor

In general, I find the way UT has set up their API not particularly professional. It's an awesome engine, and an API with awesome functionality - but it lacks proper use of namespaces, doesn't follow general .NET / Mono guidelines and in general looks like it was created by some game engine hackers. Oh, well, I guess that was how it was created. Engineers into game development FTW!!! ;-)

 

@jashan: interesting, and also very sadistic About Unity conventions, I totally hate the lack of namespaces (which becomes a mess when using plugins or naming one's classes), but about naming guidelines I just suppose they use JavaScript's.

 

It only looks sadistic until it saved you from greater pains ;-) ... at that point in time, it will reveal its true, compassionate nature.

Ah, don't get me started on JavaScript. "Functions"??? What? There really are no functions in UnityScript or C# ... and probably neither in Boo. In Web JavaScript, of course, everything is a function. But Unity has no Web JavaScript. It has a .NET/Mono-based, object oriented language which only has a syntax somewhat similar to JavaScript.

Really: These things are called "methods" because we are in an object oriented world!

And I believe JavaScript/UnityScript doesn't even have a concept of properties which is most likely why they call everything "variables" even though it's really properties (with all the potential performance implications that has - which are hidden under the innocent term "variable" ... since when can accessing a variable create a performance issue?)

Given that they call it "variables" it would be just right to have them "camelCased" but those are properties so they should really be PascalCased.

But I guess in the end, languages and naming conventions are like religion or operating systems: Discussing the rights and wrongs is a waste of time.