Programming in Unity – Conventions

Over the years I have picked up some habits from tutorials or other programmers about conventions, or better said I mainly made my assumptions about how things are supposed to be done/written. I never really looked into it basically and about the hows and whys even less.

Obviously, one thing that is important to keep in mind is:

Code is written for people to read

Because in the end the machine does not care, if we would write for the computer we would write binary and that would be of no efficiency.
So following conventions makes sense, that we as programmers understand what we are doing, and are even able to understand what other programmers have done. It makes the code more accessible and easier to maintain and extend at the same time. It also it makes the code look consistent and is a good demonstration of best practices.

Just once thing to keep in mind with conventions:
Consistency trumps style.

This applies especially at Naming Conventions
According Merriam-Webster one definition of “Name” is:

A word or symbol In logic to designate a entity
Using descriptive and easily readable names will help a lot during a coding project. Not only for one self but also for other people joining the project. It minimises guesswork.
Aside from being consistent to reinforce the habit of best practices, we shouldn’t use underscores between words, and also avoid abbreviations.

Names should be descriptive as said:

public class PlayerController() : MonoBehaviour 
{
	public string name;
    // while this keeps questions open,... 
    public string playerName;
    // this would be clearer.
    private float posX; 
    // not clear what this is for
    private float horizontalMovement; 
    // that's better
}

In C# we usually use PascalCase and camelCase.
PascalCase for:

• Classes
• Structs
• Methods
• Namespaces

camelCase for:

• Fields
• Parameters/Arguments

Underscore with private member variables

This is something I have picked up. Lately I came to understand that this is by now or always have been an Anti-Pattern.

A quick look on the Microsoft Documentation confirms:

Word Choice
✔️ DO choose easily readable identifier names.
For example, a property named HorizontalAlignment is more English-readable than AlignmentHorizontal.
✔️ DO favor readability over brevity.
The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).
❌ DO NOT use underscores, hyphens, or any other nonalphanumeric characters.
❌ DO NOT use Hungarian notation.
❌ AVOID using identifiers that conflict with keywords of widely used programming languages.
Docs.Microsoft.com

I have learned that this habit might derive from Visual Basic which hasn’t been a case sensitive language and this helped to navigate around this issue. But since C# is case sensitive it does not make much of a sense anymore to keep that alive.

Another reason people like to do this is because they find it quicker to understand. They use it as additional description.
Modern IDEs on the other hand do help a lot on inspecting the nature of a variable when you come across them.
In the case in which we would like to use the same wording for a parameter as for a private variable. We shouldn’t use underscore for the private variable, but this. This is new to me so here comes a example:

public Person(string firstName, string lastName)
{
  this.firstName = firstName;
  this.lastName = lastName;
}

To be honest, I dislike the underscores because they kind of slow me down while writing and I don’t find them aesthetically pleasing. So I can live with this convention, maybe this changes with experience… who knows.

There are also conventions in style like having one statement per line. Or something I have been doing wrong for a very long time which is having the curly bracket next to the method name:

void Start(){
  /*...*/ 
}

Because I kind of got used to it while writing JavaScript Photoshop scripts. But nowadays I think it even helps me to remind myself of the environment I am currently working in, and I think it is easier to read as well because the brackets nicely align:

void Start() 
{
  /*...*/ 
}

Something which is not precisely a convention but also helps to organise the code is to use regions:

#region Variable Declarations

public int numberToDisplay;
private int numberToMultiplyBy;

#endregion

This helps easily to show and hide code-blocks and groups them nicely. It also demands to keep things that belong together together also in the sense of location within one class.

That’s it for now.

Sources:
Learning C# by Developing Games with Unity 2019 by Harrison Ferrone
https://www.c-sharpcorner.com/article/stop-use-var-everywhere-and-think-before-use-underscore-with-private-variable-in/
https://learn.unity.com/project/c-scripting-in-unity-beyond-the-basics
https://blogs.msdn.microsoft.com/brada/2005/01/26/internal-coding-guidelines/