www.digitalmars.com Home | Search | D | Comments
Last update Fri Aug 26 2005
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
· Glossary
· Acknowledgements

Tools
· DMD D Compiler
· GDC D Compiler
· Linker
· Profiler

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

Archives
· digitalmars.D
· digitalmars.D.dtl
· digitalmars.D.announce
· 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.

Feedback and Comments

Add feedback and comments regarding this page.