C# and Unity Standards (Mark)

C# and Unity Standards (Mark)

Goal: Write consistent, well-documented C# code for Unity game development following specific naming conventions, XML documentation standards, and British spelling preferences.

When to Use This Skill

• Writing C# code for Unity
• Creating Unity MonoBehaviour scripts
• Writing C# class libraries for games
• Implementing Unity event systems
• Writing Firebase or external service integrations in Unity
• Documenting C# public APIs
• Setting up callback registration patterns

When NOT to Use This Skill

• Writing C# for non-Unity projects (use general C# standards)
• Writing code for non-gaming contexts
• Contributing to external C# projects with different conventions
• Writing in other languages (JavaScript, Python, etc.)

Process

1. Check project context - Verify this is a Unity/​C# project
2. Apply naming conventions by access level:
   • public → camelCase
   • protected → PascalCase
   • private → _camelCase
3. Methods always use PascalCase - Regardless of access level
4. Add XML documentation - For all public APIs with <summary>, <param>, <returns>
5. Use British spellings - In code identifiers and documentation
6. Implement callback pattern - Use List<Action<T>> with Register/​Fire methods
7. Format Debug.Log messages - Lowercase, consistent with error format
8. Preserve external naming - When porting code, keep original naming with source comment
9. Update AGENTS.md - Document project-specific Unity/​C# patterns

Constraints

• ALWAYS use British spellings in code identifiers and documentation (colour, initialise, behaviour)
• ALWAYS use PascalCase for methods regardless of access level
• ALWAYS use _camelCase for private fields (prefix with underscore)
• ALWAYS preserve external code naming when porting with source attribution
• NEVER use American spellings except when interfacing with Unity/​.NET APIs (Color, MonoBehaviour)
• NEVER use lowercase for method names (even private methods)
• NEVER rename external ported code - Preserve original naming for traceability
• Exception for Unity/​.NET APIs: Use their American spelling when directly referencing (Color, MonoBehaviour, Initialize)

Standards for writing C# code, with Unity-specific patterns.

Naming Conventions

Field Naming by Access Level

public double lightness;           // public: camelCase
protected Slider LightnessSlider;  // protected: PascalCase
private FirebaseAuth _auth;        // private: _camelCase

Method Naming

Methods use PascalCase regardless of access level:

public void CalculateSimilarity() { }
private void _initialiseAuth() { }  // ❌ WRONG
private void InitialiseAuth() { }   // ✅ CORRECT

Preserved External Code

When porting code from external sources, preserve the original naming for traceability:

// https://bottosson.github.io/​posts/​oklab/ (public domain)
public static Lab linear_srgb_to_oklab(RGB c)  // snake_case preserved
{
    // implementation...
}

Add a comment linking to the original source.

XML Documentation

Use XML documentation for public APIs:

/// <summary>
///     calculate a similarity percentage from a colour distance
/// </​summary>
/// <param name="delta">the delta object returned by CalculateDistance</​param>
/// <param name="chromaMax">maximum chroma value, defaults to 1.0f</​param>
/// <returns>a similarity percentage (0-100)</​returns>
public static float CalculateSimilarity(DeltaLabChE delta, float chromaMax = 1.0f)
{
    // implementation...
}

Key points:

• Use lowercase in documentation text (sentence case)
• Indent content within <summary> tags
• Include <param> for all parameters
• Include <returns> for non-void methods
• Use British spellings (colour, initialise, behaviour)

Callback Registration Pattern

Use List-based callback registration for event systems:

private readonly List<Action<FirebaseUser>> _onSignInCallbacks = new();

public void RegisterOnSignInCallback(Action<FirebaseUser> callback)
{
    _onSignInCallbacks.Add(callback);
    Debug.Log($"registering OnSignInCallback ({_onSignInCallbacks.Count})");
}

private void FireOnSignInCallbacks()
{
    foreach (var callback in _onSignInCallbacks)
    {
        try
        {
            callback.Invoke(_user);
        }
        catch (Exception e)
        {
            Debug.LogError($"error invoking callback: {e.Message}");
        }
    }
}

Pattern elements:

• Private List<Action<T>> for storing callbacks
• Public Register*Callback method
• Private Fire*Callbacks method with try-catch
• Log registration count for debugging

Debug.Log Formatting

Use lowercase messages consistent with error message format:

Debug.Log($"initialising authentication service");
Debug.Log($"registering OnSignInCallback ({_onSignInCallbacks.Count})");
Debug.LogWarning($"user not authenticated, skipping sync");
Debug.LogError($"error invoking callback: {e.Message}");

For errors, follow the standard format:

Debug.LogError($"authservice: error: failed to sign in: {e.Message}");

British Spellings

Use British spellings in code identifiers and documentation. See dev-standards-majo for the complete list.

Common C# examples:

• Initialise() not Initialize()
• colour not color
• behaviour not behavior
• Serialise() not Serialize()
• Normalise() not Normalize()

Exception: When interfacing with Unity or .NET APIs that use American spellings (e.g., MonoBehaviour, Color), use the API's spelling for that specific reference.

Testing Skills

• Naming convention check: Verify field naming by access level (public camelCase, protected PascalCase, private _camelCase)
• Method naming test: All methods use PascalCase, never lowercase or _camelCase
• XML documentation validation: Public APIs have <summary>, <param>, <returns> tags
• British spelling verification: Check colour, initialise, behaviour (not color, initialize, behavior)
• Callback pattern test: List<Action<T>> with Register/​Fire methods and try-catch
• Debug.Log format: Lowercase messages with consistent format
• External code preservation: Ported code keeps original naming with source attribution
• Unity API exception: Color, MonoBehaviour use American spelling as required by Unity

Integration

This skill extends dev-standards-majo. Always ensure dev-standards-majo is loaded for:

• British English spellings
• Error message format
• AGENTS.md maintenance
• Universal code principles

Works alongside:

• git-majo — For committing C# changes
• writing-docs-majo — For writing C#/​Unity documentation
• task-planning-majo — For planning Unity projects