Dスタイル
Dスタイル は、 Dでプログラムを書く上でのコーディングスタイルを集めたものです。 Dスタイルはコンパイラによって強制されるわけではなく純粋に見かけ上の話で、 プログラマ一人一人の選択の問題です。しかし、Dスタイルを守ることで、 あなたのコードを扱う他の人にとってわかりやすいプログラムになります。 もちろん他の人のコードをあなたが扱う時も。あなたがプロジェクトで 詳細なコーディングスタイルを定める際には、Dスタイルが叩き台となるでしょう。
Phobosへの提供コードや公式なDのソースコードはすべて、 以下のガイドラインに従います。
空白
- 1行に1文。
- タブではなく空白文字を使用する。
- インデントのレベル毎に、2つ以上の空白文字。
- 演算子とオペランドの間には空白を1つ。
- 関数定義どうしの間には空行2行。
- 関数定義のなかでは、 変数宣言と実行文の間に1つの空行。
コメント
- 一行で注釈を付け加えるときは // を:
statement; // comment statement; // comment
- 複数行の注釈には /* */
でブロックコメントを:
/* comment * comment */ statement; statement;
- 試しに書いた、文法的には正しいコードを ‘コメントアウト’ するには
version (none) を:
version (none) { /* comment * comment */ statement; statement; }
version(all) とすることで再度有効化できます。version (all) { /* comment * comment */ statement; statement; }
- 文法的に正しくないコードの ‘コメントアウト’ にはネストできる/+ +/コメントを使います:
/+++++ /* comment * comment */ { 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の定義済み演算子は慣習にのっとった使い方をしています。 ‘+’ が ‘足し算’ で ‘<<’ が ‘左シフト’、などなど。 ‘+’ 演算子を ‘足し算’ 以外の意味でオーバーロードするのは非常に混乱をまねくので、 避けるべきです。
ハンガリアン記法
変数の型を示すためにハンガリアン記法を使うのは、 悪い考えです。 しかし、変数の(型だけでは示されていないような) 使用目的を示すために使うのは、 多くの場合良い習慣といえるでしょう。
ドキュメント
すべてのpublic宣言には、 Ddoc 形式でコメントを添えます。
単体テスト
現実的な範囲で、 すべての関数は関数定義の直後にunittestブロックを置いて、 単体テストで検査します。 すべてのコードパスは最低一度はテストで実行されるようにします。 コードカバレッジ解析 で検証できます。