Skip to content

Code Style Document

Jump to bottom
Valk edited this page Aug 4, 2025 · 66 revisions

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

There's also a saying, "Rules were made to be broken". For example should it be called PlayerMovementComponent or PlayerComponentMovement? There is no wrong answer here.

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

  • PascalCase: Types, methods, properties, constants, events.
  • 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. Private Classes and Enums

Principles

Please familiarize yourself with these principles.

Clone this wiki locally