Phobos and Druntime Style Guide

Many people have contributed to the core D library Druntime and the standard D library Phobos. Over the years, the codebases have accumulated a mix of styles. Whilst each particular style is entirely fine on its own, code containing a mishmash of styles is jarring. This document sets out a number of style guidelines that all new Phobos code should follow. The plan going forward is to automate these simple rules for new pull requests and later for the entire codebase.

Indentation and Bracing

• Indentation level is four spaces.
• There is no fraction of an indent. All indentation is a multiple of 4 spaces.
• There is no triple indent or more. Double indent shall occur under specific circumstances enumerated later in this document.
• When present on their own line, template constraints are not indented extra. Example:

int fun(T)(T value)
if (isIntegral!T)
{
    ...
}

• Opening and closing braces for scopes and static if shall be on their own line. There is no other code on lines with such braces.
• In contract code, in, out, body are not indented. Example:

int fun(T)(T value)
if (isIntegral!T)
in
{
    ...
}
body
{
    ...
}
body
{
    ...
}

Whitespace

• Use empty lines in functions sparingly. If too many, that's a sign the function is too long.
• There shall not be two or more blank lines in any module.
• An open paren cannot be followed by a space.
• A closed paren cannot be preceded by a space.
• Always insert a space (except if at the end of line) after the following: catch, do, else, enum, finally, for, foreach, foreach_reverse, if, in, is, return, switch, throw, try, while, with.
• Always insert a space around all binary operators.
• Never insert a space between a unary operator and its argument.

Naming

• Module names are as_shown_here: valid D symbols containing only lowercase letters, digits, and underscores.
• Value names are asShownHere.
• Type and tempalte names are AsShownHere.
• When a symbol may refer to a type and also a value, use the convention for values.
• Generally avoid CAPS names even when abbreviations.