D スタイル

D スタイル は、 Dでプログラムを書く上でのコーディングスタイルを集めたものです。 Dスタイルはコンパイラによって強制されるわけではなく純粋に見かけ上の話で、プログラマ一人一人の選択の問題です。しかし、Dスタイルを守ることで、あなたのコードを扱う他の人にとってわかりやすいプログラムになります。もちろん他の人のコードをあなたが扱う時も。あなたがプロジェクトで詳細なコーディングスタイルを定める際には、Dスタイルが叩き台となるでしょう。

Phobosへの提供コードや公式なDのソースコードはすべて、以下のガイドラインに従います。

空白

１行に１文。
タブではなく空白文字を使用する。
インデントのレベル毎に、２つ以上の空白文字。
演算子とオペランドの間には空白を１つ。
関数定義どうしの間には空行２行。
関数定義のなかでは、変数宣言と実行文の間に１つの空行。

一行で注釈を付け加えるときは // を：

statement;	// コメント
statement;	// コメント

複数行の注釈には /* */ でブロックコメントを：
```
/* コメント
 * コメント
 */
 statement;
 statement;
```

試しに書いた、文法的には正しいコードを 'コメントアウト' するには version (none) を使います。

  version (none)
  {
    /* comment
     * コメント
     */
     statement;
     statement;
  }

version(all) とすることで再度有効化できます。

  version (all)
  {
    /* コメント
     * コメント
     */
     statement;
     statement;
  }

文法的に正しくないコードの 'コメントアウト' にはネストできる/+ +/コメントを使います：
```
/+++++
    /* コメント
     * コメント
     */
     statement;
     statement;
 +++++/
```

命名規約

一般に

複数の単語を繋いでできた名前の場合は、先頭の単語を除いて全て、最初の一文字を大文字にします。 privateメンバ変数以外では、アンダースコア '_' で始まる名前は使用しません。

int myFunc();

モジュール

モジュール名は全て小文字で。 [a..z] [0..p] [_] のみを使います。大文字小文字を区別しないファイルシステムでの問題を避けることが出来ます。

Cのモジュール

Cの関数へのインターフェイスとなるモジュールは、"c" パッケージに入れます。例えば：

import std.c.stdio;

モジュール名が全て小文字なのは同じです。

クラス, 構造体, 共用体, 列挙型, テンプレートの名前

は、キャピタライズ（先頭を大文字に）します。

class Foo;
class FooAndBar;

例外的なケースとして、型ではなく値を返すために作られたテンプレートについては、概念的に関数に近いため、キャピタライズしません。

template GetSomeType(T) {}  
template isSomeType(T) {}

関数名

関数名はキャピタライズしません。

int done();
int doneProcessing();

定数名

全て大文字で。

列挙型のメンバ名

lowerCamelCase で。

意味のないエイリアス

この手のものは：

alias void VOID;
alias int INT;
alias int* pint;

できるだけ避けましょう。

宣言の書き方

Dの宣言は左結合的なので、左寄せして書きます：

int[] x, y;	// xとyが同じ型であることがわかりやすい
int** p, q;	// pとqが同じ型であることがわかりやすい

こうすると変数どうしの関係が強調できます。Cスタイルは使わないこと：

int []x, y;	// yもint[]型なので混乱する
int **p, q;	// qもint**型なので混乱する

演算子オーバーロード

演算子オーバーロードは、言語でサポートされる基本型を拡張するための強力な道具です。しかしその強力さゆえに、読みにくいコードを作り出してしまう危険性をも秘めています。 Dの定義済み演算子は慣習にのっとった使い方をしています。 '+' が足し算で '<<' が左シフト、などなど。 '+' 演算子を足し算以外の意味でオーバーロードするのは非常に混乱をまねくので、避けるべきです。

ハンガリアン記法

変数の型を示すためにハンガリアン記法を使うのは、悪い考えです。しかし、変数の（型だけでは示されていないような）使用目的を示すために使うのは、多くの場合良い習慣といえるでしょう。
（※訳注：Hungarian Notation など参照のこと）

ドキュメント化

すべてのpublic宣言には、 Ddoc 形式でコメントを添えます。

単体テスト

現実的な範囲で、すべての関数は関数定義の直後にunittestブロックを置いて、単体テストで検査します。すべてのコードパスは最低一度はテストで実行されるようにします。これはコードカバレッジ解析で検証できます。

記事

ツール

フォーラム

コミュニティ

付録

参考書籍