Skip to content

Code Style Document

Jump to bottom
Valk edited this page Aug 9, 2025 · 65 revisions

If the following looks overwhelming to you, you can ignore it, I will refactor your pull request to align with this style.

There is also a saying, "Rules were made to be broken". For example should it be called PlayerMovementComponent or PlayerComponentMovement? There is no wrong answer here or maybe there is and I am just stubborn.

Formatting

  • Indentation: 4 spaces.
  • Line Endings: LF.
  • Curly Braces: Always expand unless the expression(s) / statement(s) are short.
  • Using Directives: Above namespace.
Code Examples 
// bad
public void Init(){
  if(_disabled)
  {
    return;
  }

  for(int x;x<3;x++){ GD.Print(x);} // Never inline blocks like this
}

// good
public void Init()
{
    if (_disabled)
        return; // Not much text between _disabled and return so removing {} is okay

    for (int x; x < 3; x++) // A little bit more text here so we use {}
    {
        GD.Print(x);
    }
}

Naming

  • Naming: Prefer PlayerHealthComponent over ComponentPlayerHealth.
  • PascalCase: Types, methods, properties, constants, events, protected fields.
  • camelCase: Private fields, local variables, method args.
  • Private fields: Always prefix with an underscore.
  • Events: Avoid prefixing events with On as subscribers should use this instead.
Code Examples 
private const int FPS_MAX; // hard to read
private const int FPSMax;  // hard to read
private const int FpsMax;  // good
public event Action OnDeactivated; // can no longer use On prefix in subscribers, avoid
public event Action Deactivated;   // good

Language Features

  • var Keyword: Never use unless the type is absurdly long.
  • C# Events: Always use over Godot signals.
  • Explicit Private Modifiers: Always specify private.
  • File Scoped Namespaces: Always use.
Code Examples 
// bad
namespace Template 
{
    // Code
}

// good
namespace Template;

// Code
// Avoid completely
[Signal] public delegate void Deactivated();

// Good
public event Action Deactivated;
// Outside functions
int health; // easy to mistake this for a local member
private int _health; // good

// Inside functions
int health; // good
var health = 100; // bad
int health = 100; // good

// Absurdly long type, this looks awful
foreach (KeyValuePair<Dictionary<int, List<string>>, List<Dictionary<int, int>>> kvp in abomination)

// Clean
foreach (var kvp in abomination)

Static

  • Public Functions: Only use for singletons, otherwise avoid if possible.
  • Private Functions: Use when possible.
  • Events: Never use unless you set them to null in _TreeExit() or Dispose(). Improper use can lead to random engine crashes.

Order of Code Structure

Godot exports being at the top of the script and private static functions near the bottom. Do not worry too much about this.

  1. Godot Exports
  2. Events
  3. Properties
  4. Fields
  5. Godot Overrides
  6. Public Functions
  7. Private Functions
  8. Private Static Functions
  9. Classes and Enums
Code Examples 
namespace Template;

public partial class EntityHealthComponent : Node
{
    // Exports
    [Export] private int _health;

    // Events
    public event Action<int> HealthChanged;

    // Properties
    public int Health { get; private set; }

    // Fields
    private int _shield;

    // Godot Overrides
    public override void _Ready()
    {
        Setup();
    }

    // Public Functions
    public void SetHealth(int health)
    {
        _health = health;
    }

    // Private Functions
    private void Setup()
    {
        // ...
    }

    // Private Static Functions
    private static void CalculateDamage(int damage, int health)
    {
        // ...
    }

    // Private Classes and Enums
    private class HealthManager
    {
        // ...
    }
}

// Small Public Classes
public class DamageModifier 
{
    // ...
}

// Public Enums
public enum HealthType 
{
    // ...
}

Principles

Some coding principles you can look at if you want. Following them helped me become a better programmer.

Clone this wiki locally