# Style Guide

- Follow C# conventions for stuff not otherwise mentioned
- Use PascalCase for the following (Things that can't change)
- Readonly/const fields
- Readonly properties
- Enum members
- Methods
- Types
- Use camelCase for the following (Things that can change)
- Fields
- Properties
- Local variables
- Method parameters
- Function/Class/Struct/Delegate/Enum Declarations should be separated by at least one empty line

    // Yes
    void OwO() {
        //...
    }
    
    void UwU() {
        //...
    }
    
    // No
    void OwO() {
        //...
    }
    void UwU() {
        //...
    }

- Acronyms should be treated like words
- `Gui`, not `GUI`
- Package names shouldn't repeat the parent(s)

    // Yes
    namespace Voxel.World.Settings;
    // No
    namespace Voxel.World.WorldSettings;

- Backing fields of properties should be named the same as the property they're backing, but prefixed with an _
- Generics should be prefixed with `T`, otherwise types (Classes/Interfaces/etc) should not be prefixed
- `Tkey` - Good
- `IBlockView` - Bad
- Braces should be on the same line, [OTB style](https://en.wikipedia.org/wiki/Indentation_style#Variant:_1TBS_(OTBS))
- Space should be in control statements like `if`, `while`, etc

        if (someCond) {
            // Do something
        }

- Control statements should always exclude braces only when all branches run one line of code
- That line of code should be on a new line

        // Yes
        if (someCond)
            DoSomething();
        else
            DoSomethingElse();
        
        // Yes
        if (anotherCond) {
            DoSomething();
        } else {
            DoSomethingElse();
            DoAThirdThing();
        }
        
        // No
        if (aThirdCond)
            DoSomething();
        else {
            DoSomethingElse();
            DoAThirdThing();
        }

- `else switch`, `else while`, etc are disallowed
- Spaces should surround math operators, except the inside of parenthesis
- `1 + 5` instead of `1+5`
- `(1 + 5) * 2` instead of `( 1 + 5 ) * 2`
- If a property only has a getter, prefer `int Value => v`;
- Prefer `=>` notation in methods/properties that immediately return.
- Prefer newline for methods

        int DoSomething(int x)
            => x * 15;

- Prefer no newline for properties

        int something => DoSomething(6) - 12;
        float somethingElse {
            get => x;
            set => x = value;
        }

- 4 spaces
- Prefer `var` when possible, as well as `new(/*...*/)`
- `var thing = new Thing();`
- Primitive types are an exception
- `int thing = 15` over `var thing = 15`
- Prefer `x as Thing` over of `(Thing) x` whenever possible
- `var thing = x as Thing`
- Always mark nullable variables as nullable
- `Thing? thing`
- `this.` should be used only when necessary
- Ordering of members in types
- Const -> readonly -> mutable
- Static -> non-static
- Public -> private -> protected -> internal
- Delegates -> fields/properties -> constructors -> methods -> sub-types
- Unsafe functions and blocks should have a comment explaining safety, like in Rust.

    // SAFETY: We know GetCString returns a valid pointer to a C String (or nullptr).
    unsafe {
        byte *ptr = GetCString();
        var str = Marshal.PtrToStringUTF8((nint)ptr);
    }

- TODOs should have a colon, not a dash

    // TODO: Do this
    // TODO - Not this