www.digitalmars.com Home | Search | D | Comments
Last update Thu Apr 27 21:15:52 2006
D
Language
Phobos
Comparisons

· Overview
· D for Win32
· Win32 DLLs in D
· C .h to D Modules
· FAQ
· Style Guide
· Example: wc
· Future
· D Change Log
· Tech Tips
· Rationale
· Warnings

Articles
· Exception Safety
· Templates Revisited

Tools
· DMD D Compiler
· GDC D Compiler
· Linker
· Profiler
· Code Coverage
· DMD Script Shell
· Windows Debugger

Community
· News
· Forum
· Announcements
· Learn
· D links

Archives
· digitalmars.D
· digitalmars.D.dtl
· digitalmars.D.announce
· digitalmars.D.dwt
· digitalmars.D.learn
· digitalmars.D.bugs
· D.gnu
· Old D

Appendices
· Glossary
· Ascii Table
· Acknowledgements

The D Style

The D Style is a set of style conventions for writing D programs. The D Style is not enforced by the compiler, it is purely cosmetic and a matter of choice. Adhering to the D Style, however, will make it easier for others to work with your D code and easier for you to work with others' D code. The D Style can form the starting point for a D project style guide customized for your project team.

Submissions to Phobos and other official D source code will follow these guidelines.

White Space

  • One statement per line.
  • Hardware tabs are at 8 column increments.
  • Each indentation level will be four columns.
  • Operators are separated by single spaces from their operands.
  • Two blank lines separating function bodies.
  • One blank line separating variable declarations from statements in function bodies.

Comments

  • Use // comments to document a single line:
    statement;	// comment
    statement;	// comment
    
  • Use block comments to document a multiple line block of statements:
    /*
     * comment
     * comment
     */
     statement;
     statement;
    
  • Use nesting comments to 'comment out' a piece of trial code:
    /+++++
        /*
         * comment
         * comment
         */
         statement;
         statement;
     +++++/
    

Naming Conventions

General
Names formed by joining multiple words should have each word other than the first capitalized. Names shall not begin with an underscore '_'.
int myFunc();
Module
Module and package names are all lower case, and only contain the characters [a..z][0..9][_]. This avoids problems dealing with case insensitive file systems.

C Modules
Modules that are interfaces to C functions go into the "c" package, for example:
import std.c.stdio;
Module names should be all lower case.

Class, Struct, Union, Enum names
are capitalized.
class Foo;
class FooAndBar;
Function names
Function names are not capitalized.
int done();
int doneProcessing();
Const names
Are in all caps.
Enum member names
Are in all caps.

Meaningless Type Aliases

Things like:
alias void VOID;
alias int INT;
alias int* pint;
should be avoided.

Declaration Style

Since in D the declarations are left-associative, left justify them:
int[] x, y;	// makes it clear that x and y are the same type
int** p, q;	// makes it clear that p and q are the same type
to emphasize their relationship. Do not use the C style:
int []x, y;	// confusing since y is also an int[]
int **p, q;	// confusing since q is also an int**

Operator Overloading

Operator overloading is a powerful tool to extend the basic types supported by the language. But being powerful, it has great potential for creating obfuscated code. In particular, the existing D operators have conventional meanings, such as '+' means 'add' and '<<' means 'shift left'. Overloading operator '+' with a meaning different from 'add' is arbitrarily confusing and should be avoided.

Hungarian Notation

Just say no.

Documentation

All public declarations will be documented in Ddoc format.

Unit Tests

As much as practical, all functions will be exercised by unit tests using unittest blocks immediately following the function to be tested. Every path of code should be executed at least once, verified by the code coverage analyzer.