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