What’s up with your coding style?

When you download a GGEZ asset, you’ll probably notice I use a pretty unique code style. My style is derived from Whitesmiths and solves a number of practical issues with other coding styles I’ve used over the last 20 years.

Here’s a sample:

namespace ggez
{
public struct Vector2i
{
public int X;
public int Y;

public Vector2i (
        int x,
        int y
        )
    {
    this.X = x;
    this.Y = y;
    }

public override bool Equals (object other)
    {
    var otherThisType = other as Vector2i;
    if (otherThisType == null)
        {
        return false;
        }
    return otherThisType.x == this.x
            && otherThisType.y == this.y;
    }
}
}

Principles

• Maximize correctness
• Maximize readability
• Assist line-based version control

Basic Rules

• Whenever a scope is created, indent one level
• Context-creating braces are on their own line and match the indent level they create
• If continuing a previous line, indent two levels past the start of the original line
• Use camelCaseNames
• Public members (functions, fields, properties) start with a capital letter
• Private members start with a lower-case letter
• Functional comments only (see exceptions)

Functional Style Goals

• Maximize correctness by catching and recovering from errors
• Maximize configurability by exposing parameters
• Minimize branching: execute all code always and throw away results
• Maximize batch processing and linear memory access
• Be aware of cache levels and garbage collection
• Avoid using object-oriented paradigms for their own sake

Exceptions

• Thorough nonfunctional comments in code released to the Asset Store
• Don’t indent namespaces or the top-level class in a file
• Break any rule necessary to make complex structured code reveal its structure
• Backing field for a property has the exact same name as the property but starts with _.
• Use an underscore to denote a variable that is an aspect of another variable