Code Style & Standards in Unity

6 min readApr 8, 2021

When applied to code, the terms Style & Standards are often used interchangeably. For me a standard is about the basic unenforced rules for how you code. For example, in the wider ecosystem of c# a public method would use upper camel case (aka Pascal case). For example;

public void SayHello()

Whereas style is subtly different, it’s about working within a standard to reflect how you, or your team, work. For example you might decided that all public methods should have a Noun-Verb style, so the previous example would become;

public void HelloSay()

Unity you Maverick

When you start to code in Unity with c# you will notice that it has some…interesting styles & standards and a strong blurring between the two.

The underscore

Using an underscore to denote a member field is one of those blurred style/standards that does exist outside of Unity.

private int count = 0;
private int _count = 0;

It used to be very prevalent and fell out of favor about the same time as c# was released. I believe it was partly because IDEs such as Visual Studio started to make heavy use of ‘intellisense’ hints and partly down to the coding standards of the time. E.g. to access a private member field the coding standard was to prefix it with ‘this’

public void SayHelloManyTime(int count)
// the next line doesn't use the param
if (this.count > 10)...

The ‘this’ makes it very clear that you are dealing with a member field and it will not be confused with any other variable that might even have the same name. You do NOT see this standard in Unity code, so the following would be an ambiguous mess

private int count = 0;
public void SayHelloManyTime(int count)
// what variable will the next line use??? (it's the param)
if (count > 10)...

So if you are not going to use ‘this’ then adding an underscore makes sense, this is the Unity way.

private int _count = 0;
public void SayHelloManyTime(int count)
if (_count > 10)...

Casing in Unity

Using underscores in your code is an example of what people in the UK refer to as a ‘Marmite’ choice — you probably either love it or hate it, there really isn’t a middle ground. But it’s a standard so you are going to have to learn to love it. Casing on the other hand…ooh this is a painful one.

I believe, and please correct me, that Unity used to have one foot in c# and the other in JavaScript. The problem here is that JavaScript has different coding standards. However, if you are writing a framework for a game engine then you probably only want to write it once (although you could get around this problem). So I believe that some parts of Unity you see are more aligned to JavaScript than c#. For example;

this.transform.position
this.CompareTag("Player");

I’ve included the ‘this’ to make the code obvious (I miss ‘this’). The first line is telling Unity to use the Transform property to get the Position property. The second is invoking a method called CompareTag.

“Hi, my name’s Paul and I’ve been using Unity for over 2 years now, and I endorse this standard”. “Hi, my name’s Old Paul from 3 years ago, I’ve just read the above line and I’ve vomited down my legs”.

I feel sorry for ‘Old Paul’, it would almost feel like a sack-able (fired) offense for using camel case on a public property. But I have got used to it. However, since the public properties are now using the same camel-casing as private fields it again highlights the need to use underscores;

// oh dear....
private Transform transform;
public Transform transform {get;]

Having said all of that, if I write new code I’m still using Pascal casing for my public properties, I’m not going to die on this hill but for now…

Unity’s inheritance

This is more of a style from Unity themselves than a standard but I am including it here because I see a lot of people getting confused.

var gameobject = this.transform.gameObject;
var gameObject2 = this.gameObject;

A lot of objects/components in Unity share a common base class. That means that you will see a large number of what look like duplicate functions and properties, but in reality they are the same. In Visual Studio (and I’m sure every other IDE) you can check this by right-clicking on the function/property in question and selecting ‘Go to definition’

As you can see they’re exactly the same, so from a style perspective just use the one that offers the best, and most explicit, explanation of what you’re trying to do.

Why are standards important?

Why should anyone care about styles & standards? They are very important because;

Easier to learn the subject — if you adopt the same style and standards as the majority of Unity developers you will be able to read their code, and they yours
Team work — when you work in a team you want people to be able to consume your code as easily as possible, if everyone is using the same style & standards then this is much easier. “Have a got a verb-action method for this, let me type “Get…ah there it is…”
Maintenance — having a consistent style & standards makes it a lot easier to change code
Legal — probably not one that springs to mind for most Unity developers but when you deliver code you do have a responsibility for the quality of your work. This is important if you sell your work, especially in an corporate/enterprise arena. One way to demonstrate that your care about the quality of your work is by adhering to a working set of style & standards. This is really a nice side-effect, hopefully you should already be convinced without needing this point.

Other standards?

This article has focused on coding style & standards but there are other areas that should be considered too.

Project Structure — how you structure your project is important for all the same reasons. If someone wants to edit a script then they should know where it is likely to be. Unfortunately there does not seem to be a standard for this, so it is up to you and your team to publish and evolve these for yourself
Scene Hierarchy — Similar to Project Structure but this about how you structure the objects in the scene hierarchy and how to name them. Tracking items with poor names can make your life very difficult.

Summary

Unity’s coding style & standards is a little bit strange, but it is what it is. You will have a much easier life if you largely adopt them rather than fight against them. Having a working knowledge of them will make it a lot easier for you to work with other Unity developers and designers — even if perhaps you might secretly believe they have no style

My coding style recommendations & standards

Just sharing a little sample of what I work to

private int _underscoreCamelCasePrivateFields;
private float PascalCaseProperties => _camelCaseField;
private PascalCaseMethodsOrFunctions() {}
public async Task SuffixAsyncMethodsWithAsync() {}
public void DoNotUseJavascriptBlocks()
{
  if (_thisCodeIsJavaScript) {
  }
  
  if (_thisCodeIsCSharp)
  {
  }
}// never omit a code block
if (_thisCodeIsNaughty) DoSomethingBad();if (_thisCodeIsGood)
{
   DoSomethingNice();
}// Do Not Use bools For State Flags, an enum is a flag
bool isStateOff = false;
bool isStateOn = false;
bool isDimmed = false;[Flags]
private enum State
{
    Off = 0,
    On = 1,    
    Dimmed = 2
}