www.digitalmars.com Home | Search | D | Comments
Last update Sat Mar 18 10:52:50 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
· Exception Safety
· Templates Revisited
· Warnings
· Glossary
· Acknowledgements

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

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

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.

White Space

  • One statement per line.
  • Two or more spaces per indentation level.
  • 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 works should have each word other than the first capitalized.
int myFunc();
Module
Module names are all lower case. 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.