Note: This website is archived. For up-to-date information about D projects and development, please visit wiki.dlang.org.

As there is no general consensus about which coding standards are the best, many of the following rules were chosen randomly. Yet, they should be followed strictly to prevent the code base from degrading into a mess.

D code

One level of indentation spans 4 space characters (U+0020). Whitespace characters other than spaces, line feeds or carriage returns are not allowed.

Follow the ANSI style:

void main()
{
   while (true)
   { // the brace is on the new line
       something;
       more;
   }        
}

Braces are required for blocks of code that span more than one line. If there is a single statement in the block, do not place the statement on the same line with the preceding statement.

Wrong:

while (x < y)
    // comment
    something;

for (int i = 0; i < j; ++i)
    while (x < y)
        if (z) something;

Right:

while (x < y)
{
    // comment
    something;
}

for (int i = 0; i < j; ++i)
{
    while (x < y)
    {
        if (z)
           something;
    }
}

If a statement takes a list of arguments in parentheses, it is recommended to insert a space between the statement and the list as shown in the examples above.

Avoid spaces after the opening and before the closing parentheses.

Wrong:

if ( x < cast( int )y )
    something;

For muti-line comments, prefer the following style:

/**
    Comment
 */

Do not use comment artistry:

/****************************************************************************
 ************* I am a Pablo Picasso *****************************************
 ***************************************************************************/

Place data field declarations of a class at the top of the class body:

class A
{
    int x;
    int y;

    // other members
}

Generally, avoid redundancies. For example, do not tag declarations with unnecessary protection attributes. They add nothing but noise.

Wrong:

public class A
{
   public void foo() {}
   public void bar() {}
}

Right:

class A
{
   void foo() {}
   void bar() {}
}

Argument-less function calls should be done with an empty argument list unless the function is tagged with the @property attribute:

void foo() {}

@property
int bar() { return 0; }

void main()
{
    foo();
    auto x = bar;
}

Naming conventions

Names of user-defined types are UpperCamelCase.

Naming of templates depends on the result of their instantiation. If an instantiation of the template results in a type or type tuple, write the template name in UpperCamelCase, otherwise, in lowerCamelCase:

template Type(T)
{
    alias T Type    
}

template isType(alias t)
{
    enum isType = is(t);
}

Other symbols, including enum members should be written in lowerCamelCase.

Decorate the names of non-public data fields with a leading underscore:

class A
{
    private int _x;
    void x()
    {
        return _x;
    }
}

QtD names that are likely to cause conflicts with user-defined names should start with "qtd" or "Qtd" pseudo-namespaces.

int qtdFoo;
alias int QtdInt;

External functions that wrap native Qt functions should be named as follows:

qtd_nativeFunctionName

or

qtd_nativeFunctionName_a1_a2_..._aN

where a1 ... aN are type names of arguments (encoded to exclude characters not allowed in identifiers)