Naming Conventions Decoded: How To Name Things (And Why)

Welcome to another blog post about most likely the least exciting topic in programming that will quietly save you the most time: naming conventions in C#. You'll notice that over time, you'll adhere to your own naming convention; however, there is a general guideline for naming variables, etc. Also, naming is how past you leaves notes for future you, so let's make those notes readable!! 

Let's dive in!

Why Do Naming Conventions Matter?

A naming convention is just an agreed-upon style for how you write names, so every name tells you what kind of thing it is at a glance. The compiler doesn't care either way. You do, because you'll spend far more time reading code than writing it.

Here's a script with a perfectly valid, perfectly miserable naming style:

public class player : MonoBehaviour
{
    public int h = 100;
    public float s = 5;
    bool b;

    void dmg(int d)
    {
        h -= d;
    }
}
  

It runs. But what's s? Speed? Score? Stamina? And what the hell does b track? Now the same script with decent names:

public class Player : MonoBehaviour
{
    [SerializeField] private int health = 100;
    [SerializeField] private float moveSpeed = 5f;
    private bool isGrounded;

    public void TakeDamage(int amount)
    {
        health -= amount;
    }
}
  

Same logic, zero guesing. You can almost read that script like a sentence, and so can the teammate (or future you) who opens it later.

Naming Conventions In C#: The Rules Most Devs Follow

C# has a widely used set of style rules, and Unity's own code follows them. Here's all of it in one snippet:

public enum WeaponType { Sword, Bow, Staff }

public interface IDamageable
{
    void TakeDamage(int amount);
}

public class PlayerController : MonoBehaviour, IDamageable
{
    private const int MaxHealth = 100;     // constant: PascalCase

    private int currentHealth;             // private field: camelCase
    private bool isGrounded;               // boolean: reads like a question
    private WeaponType weaponType;         // field named after its type

    public int CurrentHealth => currentHealth;   // property: PascalCase

    public void TakeDamage(int amount)           // method: a verb, PascalCase
    {
        currentHealth -= amount;
    }
}
  

That one script shows nearly every rule you need:

• Classes, structs, enums, and interfaces - PascalCase. Interfaces also start with a capital I, like IDamageable.
• Methods and properties - PascalCase. Unity's own methods (Awake, Start, Update) follow this too, so yours will match.
• Private fields, local variables, and parameters - camelCase.
• Constants - PascalCase in standard C# style. Some teams prefer ALL_CAPS, which is fine as long as you pick one.

PascalCase Vs camelCase: Which Goes Where?

If the names sound confusing, here's the difference. PascalCase capitalizes the first letter of every word: PlayerController, TakeDamage. camelCase does the same but leaves the very first letter lowercase, like a camel's hump rising in the middle: currentHealth, moveSpeed.

The rule of thumb for PascalCase vs camelCase is simple. Names that other code reaches for (types, methods, properties) get PascalCase. Names that live inside a class or method (private fields, locals, parameters) get camelCase. So when you see health versus Health in someone's code, you instantly know which one is the private field and which one is the public property.

Naming Booleans, Methods, And Everything Else

Casing is only half the story. The words you pick matter just as much:

• Booleans read like questions - isGrounded, hasKey, canJump. Then if (isGrounded) reads like plain English.
• Methods start with a verb - SpawnEnemy, TakeDamage, LoadLevel. A method does something, so its name should say what.
• Skip cryptic abbreviations - currentHealth beats curHP. You're typing with autocomplete, so length is free.
• Single letters are fine for tiny scopes - i in a quick loop is fine. x as a class-level field is not.

The Private Field Debate: To Underscore Or Not To Underscore

You'll probably have seen some codebases that write private fields as _health, with a leading underscore. Others write plain health. Both are common in Unity projects, and neither is wrong.

Pick whichever you like and use it everywhere, because consistency beats cleverness every time. I personally use the underscore variant because the underscore has one real benefit. When a parameter and a field share a name, the prefix keeps them apart without needing this.health = health.

Unity Naming Conventions Beyond Code: Files, Prefabs, And Objects

Good Unity naming conventions don't stop at your scripts. A few habits that pay off fast:

• Match the file name to the class name. PlayerController lives in PlayerController.cs. For a MonoBehaviour, Unity needs them to match, or you can't attach the script.
• No spaces in file and folder names. They cause odd problems with tools and build scripts.
• Use a consistent pattern for assets. Names like Enemy_Goblin and Enemy_Skeleton sort together in the Project window, which beats hunting through an alphabetical pile.
• Rename your Hierarchy objects. A scene full of GameObject (17) and Cube (3) is a puzzle nobody wants.

So Which Approach Should You Actually Use?

Here's a summarized version: the check you can run through in your head:

• Class, method, property, enum, or interface → PascalCase
• Private field, local variable, or parameter → camelCase, which is the heart of PascalCase vs camelCase
• True or false value → start it with is, has, or can
• Method → start it with a verb
• Script file → name it exactly like its class
• Project assets → follow your own consistent Unity naming conventions, with a shared prefix for related things
• Not sure → copy the style Unity's own code uses, then stay consistent

The best naming convention is the one you actually follow every time. A slightly imperfect style used consistently beats a perfect style used on Mondays.

Wrapping Up

Naming conventions are the cheapest improvement you can make to your code, since they cost nothing and speed up everything you do afterward. Learn the handful of naming conventions in C# above, use them from your very first script, and the habit will carry you through every project, every teammate, and every six-month break. 

 ~happy Coding!