これはGoogle C++ Style Guide (3.133)の日本語訳です。
Artistic License/GPLで配布します。
最終更新: 2009-03-30

Revision 3.133

Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray
（日本語訳 Takashi Sasai）
このスタイルガイドには詳細情報がたくさん含まれているが、最初は表示されていない。左端にある矢印ボタンをクリックしてみよう。 「やったね」と表示されるはずだ。

やったね! このように矢印ボタンをクリックすると詳細情報が表示される。 このドキュメントの先頭にある大きな矢印ボタンをクリックしてもいい。詳細情報が全部表示される。

C++は、Googleのオープンソースプロジェクトの多くで使われている主要な開発言語だ。 C++プログラマなら誰でも知っているように、C++には強力な機能がたくさんあるが、その力ゆえに複雑になってしまっている。コードはバグを生みやすく、読みにくくメンテナンスしにくくなるおそれがある。

このガイドの目標は、C++コードを書くときにすべきことすべきでないことを詳しく説明することで、C++にある複雑さを何とかしようというものだ。ここに挙げたルールは、C++の機能を利用して生産性を上げながらも、コードベースを管理可能にしておくためにある。

スタイルとは読みやすさのことでもあり、C++コードに適用する規約を指している。ここで「スタイル」という用語を使うのは、やや語弊があるかもしれない。規約にはソースファイルの書式以上のものが含まれているためだ。

コードベースを管理可能にする方法の1つは、強制的に一貫性を持たせることだ。どんなプログラマでもコードを見ればすぐに理解できる、ということは極めて重要なことだ。 みんなが一貫性のあるスタイルを維持して規約に従うと、簡単な「パターンマッチング」によって、各種シンボルが何を意味していて、どの不変式が真であるのか、推測できるようになる。よく使うイディオムやパターンを作っておくと、コードは非常に理解しやすくなる。スタイルを曲げるのに十分な理由があるときもあるだろう。しかし、それでもなお、私たちは一貫性を維持するため、そのままにしている。

このガイドが解決するもう1つの問題は、肥大化したC++の機能についてだ。 C++は数多くの先進的な機能を備えた、巨大な言語だ。場合によっては、特定の機能を制限したり、禁止することまでしている。コードをシンプルにして、こうした機能によって引き起こされる間違いや問題を回避するためだ。このガイドではそのような機能を列挙して、なぜその使用を制限したのかについても説明する。

Googleによって開発されているオープンソースプロジェクトは、このスタイルガイドに従っている。

このガイドはC++のチュートリアルではないことに注意しよう。読者はC++をよく知っていることを想定している。

一般的に、すべての .ccファイルには、対応する.hファイルを用意するべきだ。ただし、ユニットテストやmain()関数1つだけの小さな.ccファイルなどはこの限りではない。

ヘッダファイルを正しく使うと、コードの読みやすさ、サイズ、パフォーマンスを大きく改善することができる。

以下のルールでは、ヘッダファイルを使うときの落とし穴について説明する。

多重インクルードを防ぐために、ヘッダファイルには #defineガードを入れておくべきだ。シンボル名は <PROJECT>_<PATH>_<FILE>_H_ という書式にするべきだ。

シンボル名が一意であることを保証するために、シンボル名はプロジェクトのソースツリーのフルパスに基づいたものにするべきだ。例えば、foo というプロジェクトの foo/src/bar/baz.h というファイルの場合、#define ガードは次のようになる。

#ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ ... #endif // FOO_BAR_BAZ_H_ 前方宣言で十分なときには、#include を使ってはいけない。

ヘッダファイルをインクルードすると依存関係ができて、そのヘッダファイルを変更するたびに再コンパイルが必要になる。あなたの書いたヘッダファイルが他のヘッダファイルをインクルードしているとしよう。インクルードしているヘッダファイルを変更すると、あなたのヘッダファイルをインクルードしている他のコードもすべて再コンパイルが必要になる。そのため、インクルードするのは最小限にしておくことが望ましい。特にヘッダファイル中で他のヘッダファイルをインクルードするのは避けよう。

前方宣言を使うと、ヘッダファイル中でインクルードするヘッダファイルの数をかなり減らすことができる。例えばヘッダファイルで File クラスを使っていても File クラスの宣言にアクセスする必要がないのであれば、ヘッダファイルには class File; と前方宣言するだけで十分だ。#include "file/base/file.h" とする必要はない。

Foo クラスの定義にアクセスせずに、そのヘッダファイルでは Fooクラスをどのように利用できるのか？

  • Foo* 型や Foo& 型のデータメンバを宣言することができる。
  • Foo 型の引数や戻り値を持つ関数を宣言（定義ではない）することができる。
  • Foo 型のスタティックデータメンバを宣言することができる。スタティックデータメンバはクラス定義の外部に定義されるためだ。

これに対して、書いているクラスが Foo のサブクラスであったり、そのクラスに Foo 型のデータメンバがあるのなら、Foo のヘッダファイルをインクルードしなければならない。

メンバとしてオブジェクトではなくポインタ（scoped_ptr の方が望ましい）を持たせる方が理にかなっている場合もある。しかしこうすると、コードは読みにくくなり、パフォーマンス面でも不利になる。もしヘッダファイルのインクルードを最小限にすることだけが目的であれば、こうした置き換えをするのは避けること。

言うまでもないことだが、通常 .cc ファイルには利用するクラスの定義が必要になるため、ヘッダファイルをインクルードする必要がある。

インライン関数を定義するのは関数が小さいときのみ（10行以下）にする。 コンパイラが通常の関数呼び出しメカニズムで呼び出すのではなくインライン関数として展開するよう、関数を宣言することができる。 インライン化される関数が小さければ、コンパイラは効率のよいオブジェクトコードを生成することができる。アクセサやミューテータ、短くてパフォーマンスに影響を及ぼす関数は遠慮なくインライン化すること。 インライン化しすぎると、実際にはプログラムが遅くなることがある。関数の大きさによってコードサイズが増えたり減ったりするためだ。ごく小さなアクセサ関数をインライン化すると通常はコードサイズが減る。しかし、巨大な関数をインライン化するとコードサイズが劇的に増えることがある。最新のプロセッサでは通常、コードが小さければ小さいほど高速に実行することができる。これは命令キャッシュの利用効率が上がるためだ。

これについては優れた経験則がある。10行を超える関数はインライン化しないというものだ。ただしデストラクタには注意すること。見た目以上に長くなることがよくある。これは暗黙のうちに、メンバクラスのデストラクタとベースクラスのデストラクタが呼び出されるためだ。

もう1つ役に立つ経験則がある。ループやスイッチ文のある関数をインライン化するのは割に合わない。（ただし、よく見かける実行されることのないループやスイッチ文の場合を除く）。

たとえ関数をインライン化するよう宣言してあっても実際にインライン化されるとは限らない、ということを知っておくことは重要だ。例えば、仮想関数や再帰関数は通常インライン化されない。再帰関数は通常インライン化すべきではない。仮想関数をインライン化する主な理由は、仮想関数をクラスの定義に置くためだ。こうすると便利だから、あるいは、アクセサやミューテータなどの動作を明記できるためだ。

複雑なインライン関数を定義するときには、必要に応じて -inl.hというサフィックスを持つファイルに書いてもよい。

インライン関数の定義はヘッダファイルに入れておく必要がある。これにより、コンパイラはその定義を呼び出し場所に埋め込むことができる。しかし、実装コードはきちんと .cc ファイルに置いておくべきだ。読みやすさやパフォーマンスにメリットがない限り、実際のコードを.h ファイルにたくさん置くのは好ましくない。

もしインライン関数の定義が短くて、ロジックがほとんどないかあっても少しなら、.h ファイルにコードを入れておくべきだ。例えば、アクセサやミューテータは必ずクラス定義の内部に入れておくべきだ。もっと複雑なインライン関数であっても実装者や利用者にとって便利であれば、.h ファイルに置いても構わない。しかし、.h ファイルが大きくなりすぎて扱いにくければ、別の -inl.h ファイルにコードを入れてもいい。 こうするとクラス定義から実装が分離されてしまうが、実装はきちんと必要な場所にインクルードされる。

-inl.h ファイルのもう1つの使い道は関数テンプレートの定義だ。テンプレートの定義を読みやすくしておくためにこのファイルを使うことができる。

-inl.h ファイルには #define ガードが必要だということを忘れないこと。これについては他のヘッダファイルと全く同じだ。

関数を定義するときには、パラメータの並び順は入力、出力とする。

C/C++ 関数におけるパラメータは、関数への入力か、関数からの出力か、その両方であるかのいずれかだ。通常、入力パラメータは値か const リファレンスになる。これに対して、出力および入出力パラメータは非 const ポインタになるだろう。関数パラメータを並べるときには、出力パラメータの前に入力のみのパラメータをすべて置いておくこと。新しいパラメータだからといって、関数の最後に追加してはいけない。入力のみのパラメータを新しく追加するときには、出力パラメータの前に置くようにすること。

これは厳格なルールではない。入力でもあり出力でもあるパラメータ（クラスや構造体であることが多い）が存在するため、このルールはすっきりしていない。例によって、関連する関数に一貫性を持たせるためにルールを曲げる必要があるかもしれない。

読みやすくするため、また依存関係が隠れてしまうのを避けるために、次の順序でインクルードする。 Cライブラリ、C++ライブラリ、その他のライブラリの.h、プロジェクトの.h

プロジェクトのヘッダファイルはすべて、プロジェクトのソースディレクトリ配下にあるものとして書くべきだ。UNIXディレクトリのショートカットである .（カレントディレクトリ）や ..（親ディレクトリ）を使ってはいけない。例えば、 google-awesome-project/src/base/logging.h をインクルードするときには、以下のようにする。

#include "base/logging.h"

dir/foo.cc の主たる目的が dir2/foo2.h にあるものを実装することであったり、テストすることであれば、dir/foo.cc ではヘッダを次の順序でインクルードする。

  1. dir2/foo2.h （望ましい場所 — 詳しくは下を参照）。
  2. Cシステムファイル
  3. C++システムファイル
  4. その他ライブラリの .h ファイル
  5. プロジェクトの .h ファイル

ここで推奨している順序にすると、依存関係が隠れてしまいにくくなる。私たちはすべてのヘッダファイルがそれだけでコンパイルできるようにしたい。これを実現するいちばん簡単な方法は、すべてのヘッダファイルを必ず .cc でインクルードされる最初の .h にしておくことだ。

dir/foo.cc と dir2/foo2.h は同じディレクトリに置いておくことが多い。（例えば base/basictypes_unittest.cc と base/basictypes.h）。しかし別のディレクトリに置いても構わない。

それぞれのセクション内では、アルファベット順にインクルードしておくとよい。

例えば、google-awesome-project/src/foo/internal/fooserver.cc のインクルードは次のようになる。

#include "foo/public/fooserver.h" // Preferred location. #include <sys/types.h> #include <unistd.h> #include <hash_map> #include <vector> #include "base/basictypes.h" #include "base/commandlineflags.h" #include "foo/public/bar.h" .cc ファイルには無名の名前空間を使うことを推奨する。名前付き名前空間を使うときには、プロジェクト名と可能ならパス名に基づいた名前にする。 using ディレクティブを使ってはいけない。 名前空間はグローバルスコープを個別の名前の付いたスコープに分割する。これはグローバルスコープで名前の衝突が起こるのを避けるのに役立つ。

名前空間はクラスによる（階層的な）名前の軸に加えて、（これもまた階層的な）名前の軸を提供する。

例えば異なる2つのプロジェクトにおいて、どちらにもグローバルスコープに Foo というクラスがある場合、コンパイル時もしくは実行時にシンボルが衝突してしまうおそれがある。それぞれのプロジェクトの名前空間にコードを置いていれば、project1::Foo と project2::Foo という異なるシンボルになり衝突は起こらない。

名前空間があると混乱するおそれがある。クラスによる名前の（階層的な）軸に加えて、さらに名前の（階層的な）軸を提供するためだ。

ヘッダファイルに無名のスコープを使うと、C++の単一定義規則（ODR、One Definition Rule）に違反しやすくなる。

名前空間を使うときには次に説明するポリシーに従うこと。

  • 実行時の名前の衝突を避けるために .cc ファイルには無名の名前空間を使ってもよい。むしろ使うことを推奨する。 namespace { // .cc ファイルにおいて // 名前空間の内容はインデントしない enum { kUnused, kEOF, kERROR }; // 共通で使うトークン。 bool AtEof() { return pos_ == kEOF; } // 名前空間のEOFを使う。 } // namespace

    しかし、特定のクラスに関連するファイルスコープ宣言は、無名の名前空間のメンバとしてではなく、型やスタティックデータメンバ、スタティックメンバ関数としてそのクラスに宣言してもよい。この例にあるように、無名の名前空間を終了するときには // namespace というコメントを入れておくこと。

  • .h ファイルには無名の名前空間を使ってはいけない。

名前付き名前空間は次のようにすべきだ。

  • 名前空間には、インクルード、 gflags 定義/宣言、他の名前空間にあるクラスの前方宣言をすべて包むようにする。 // .h ファイルにおいて namespace mynamespace { // 宣言はすべて、名前空間のスコープ内にある。 // インデントのないことに注意すること。 class MyClass { public: ... void Foo(); }; } // namespace mynamespace // .cc ファイルにおいて namespace mynamespace { // 関数定義は名前空間のスコープ内にある。 void MyClass::Foo() { ... } } // namespace mynamespace

    .cc ファイルは通常もっと複雑で、他の名前空間にあるクラスも参照する必要があるだろう。

    #include "a.h" DEFINE_bool(someflag, false, "dummy flag"); class C; // グローバルな名前空間におけるクラスCの前方宣言 namespace a { class A; } // a::A の前方宣言 namespace b { ...code for b... // コードの左には余白を入れていない。 } // namespace b
  • 名前空間 std には何も宣言してはいけない。たとえ標準ライブラリに含まれるクラスの前方宣言であってもだ。名前空間 std に宣言したときの動作は定義されていない。つまり移植性がないということだ。標準ライブラリに含まれている要素を宣言するには、適切なヘッダファイルをインクルードすること。
  • using ディレクティブ を使って、名前空間にある名前をすべて利用できるようにしてはいけない。 // 禁止されている -- これは名前空間を汚染する。 using namespace foo;
  • .cc ファイルならどこでも、.h ファイルなら関数かメソッドかクラス内であれば、using ディレクティブ を使ってもよい。 // .cc ファイルではOK。 // .h ファイルでは関数かメソッドかクラス内でなければならない。 using ::foo::bar;
  • .cc ファイルならどこでも、.h ファイルなら関数かメソッド内であれば、名前空間のエイリアスを使ってもよい。 // .cc ファイルではOK。 // .h ファイルでは関数かメソッド内でなければならない。 namespace fbz = ::foo::bar::baz;
もしそれがインタフェースの一部であるときには、パブリックなネストされたクラスを使ってもよい。しかし、グローバルスコープの外部に宣言するためであれば、名前空間の使用を検討すること。 クラスはその内部に別のクラスを定義することができる。これは メンバクラス と呼ばれることもある。 class Foo { private: // Bar はメンバクラスであり、Fooの内部にネストされている。 class Bar { ... }; }; ネストされたクラス（またはメンバクラス）は、それを囲んでいるクラスによってのみ使われるときに役立つ。そのクラスをメンバにすることによって、クラス名で外部のスコープを汚染することなく、囲んでいるクラスのスコープ内に留めることができる。ネストされたクラスは、それを囲んでいるクラス内部に前方宣言しておいて、.cc ファイルで定義してもよい。こうするとネストされたクラスの定義を入れなくて済む。ネストされたクラスの定義は通常、実装だけに関連しているためだ。 ネストされたクラスはそれを囲んでいるクラスの定義の内部でのみ前方宣言することができる。したがって Foo::Bar* ポインタを操作するヘッダファイルにはみな、Foo のクラス宣言をすべて入れておく必要があるだろう。 実際にはインタフェースの一部でないときには、ネストされたクラスをパブリックにしてはいけない。例えば、メソッドのためのオプションを保持するクラスなどだ。 グローバル関数を使うよりも、名前空間内の非メンバ関数やスタティックメンバ関数を使う方が望ましい。グローバル関数はめったに使ってはいけない。 非メンバ関数とスタティックメンバ関数が役に立つことがある。非メンバ関数を名前空間内に置くと、グローバルな名前空間の汚染を防ぐことができる。 非メンバ関数とスタティックメンバ関数は新しいクラスのメンバとして使うなら理にかなっているだろう。特に外部リソースにアクセスしたり、大きな依存関係がある場合には意味がある。

クラスのインスタンスに関連付けられていない関数を定義するのは役に立つこともあるし、時として必要になることもある。こうした関数はスタティックメンバ関数または非メンバ関数のいずれかにして構わない。 非メンバ関数は外部変数に依存するべきではなく、ほとんどの場合、名前空間内に存在するようにすべきだ。スタティックデータを共有していないスタティックメンバ関数をまとめたいときには、そのためだけにクラスを作るのではなく、代わりに名前空間を使うべきだ。

クラスと同じコンパイル単位に定義されている関数を別のコンパイル単位から直接呼び出すと、コンパイル時やリンク時に不必要な依存関係ができるおそれがある。スタティックメンバ関数の場合、特にこうなることが多い。新しいクラスを抽出したり、できれば別のライブラリの名前空間に関数を置くことを検討すること。

もし非メンバ関数を定義する必要があり、それが .cc ファイル内でのみ必要なら、無名の名前空間か static リンク （例えば static int Foo() {...}）を使ってスコープを制限すること。

関数内で使う変数はできるだけスコープを限定し、宣言時に変数を初期化しておく。

C++では関数内のどこでも変数を宣言することができる。私たちはできるだけスコープを局所的にして、できるだけ初めて使う場所の近くで宣言することを推奨する。こうしておくとコードを読む人にとって、その変数の型が何であり、それがどう初期化されているのかが見つけやすくなる。具体的には、宣言や代入などを使う代わりに初期化を使うべきだ。

int i; i = f(); // よくない -- 初期化が宣言と分離している。 int j = g(); // よい -- 宣言で初期化されている。

gcc は for (int i = 0; i < 10; ++i) を正しく実装していることに注意しよう。(i のスコープは for ループ内だけになる)。そのため、同じスコープにある別の for ループで、i をもう一度利用することができる。また、if や while 文における宣言のスコープも正しく実装されている。

while (const char* p = strchr(str, '/')) str = p + 1;

1つ注意しておくべきことがある。変数がオブジェクトの場合、そのスコープに入るたびにコンストラクタが実行されてオブジェクトが生成される。そしてスコープから抜けるたびにデストラクタが実行されることになる。

// 効率のわるい実装 for (int i = 0; i < 1000000; ++i) { Foo f; // コンストラクタとデストラクタはそれぞれ1000000回呼び出される。 f.DoSomething(i); }

したがって、ループ内で使う変数は、ループの外側で宣言しておく方が効率がよいかもしれない。

Foo f; // コンストラクタとデストラクタはそれぞれ1回だけ呼び出される。 for (int i = 0; i < 1000000; ++i) { f.DoSomething(i); } クラス型のスタティック変数またはグローバル変数の使用を禁止する。これらは生成と解放の順序が不定であるため、見つけにくいバグを引き起こす。

グローバル変数やスタティック変数、スタティッククラスメンバ変数、関数スタティック変数を含む静的記憶域期間のあるオブジェクトは、POD（Plain Old Data）でなければならない。PODとは、int、char、float、voidと、これらの配列、構造体、ポインタだけだ。スタティック変数は関数の結果で初期化してはいけない。そして、非constスタティック変数はマルチスレッドのコードで使ってはいけない。

C++では、コンストラクタ、デストラクタ、スタティック変数のイニシャライザが呼ばれる順序は部分的にしか決まっておらず、ビルドするたびに変わるおそれがある。このため、発見困難なバグを引き起こすおそれがある。例えば、プログラム終了時にスタティック変数は破壊されるかもしれないが、まだ動いているコードが（おそらく別のスレッドで）その変数にアクセスしようとして失敗するかもしれない。

結局のところ、スタティック変数はPODデータを含むときにだけ使ってもよい。このルールは vector、string、とにかく任意のクラスのインスタンスを含んだり指しているものは、スタティック変数の一部になることが許されない、ということだ。似たような理由で、スタティック変数が関数呼び出しの結果で初期化されることも許されない。

もしクラス型のスタティック変数やグローバル変数が必要であれば、main() 関数や pthread_once() 関数から決して free されることのないポインタを初期化することを検討しよう。

static クラスメンバ変数はグローバル変数とみなされることに注意すること。したがってクラス型にしてはいけない。

クラスはC++コードの基本単位だ。もちろん、私たちも至るところでクラスを使っている。このセクションでは、クラスを書くときにすべきことすべきでないことを列挙する。 コンストラクタでやることは簡単な初期化だけにする。もし簡単でなければ、できる限り Init() メソッドを使うこと。 コンストラクタ本体で初期化をすることができる。 入力に好都合。クラスが初期化されているかどうかを気にする必要がなくなる。 コンストラクタで初期化をするのには、いくつか問題がある。
  • 例外以外にコンストラクタがエラーになったことを知る簡単な方法がない（外を使うことは禁止されている）。
  • もし処理に失敗すると、初期化が完了していないオブジェクトが得られてしまう。このオブジェクトは不定状態になるおそれがある。
  • もしコンストラクタで仮想関数を呼び出していると、この呼び出しはサブクラス実装に対してディスパッチされない。 たとえ今のところはサブクラス化されていなくても、後になってサブクラス化したときにこの問題が入り込んでしまい、大きな問題になるおそれがある。
  • 誰かがクラス型のグローバル変数を作ってしまうと（これはルールに反しているが、それでも作ってしまった場合）、コンストラクタのコードは main() 関数よりも前に呼び出されることになる。おそらくこれは、コンストラクタのコードにとっては想定外のことだろう。 例えば gflags はまだ初期化されていない。
オブジェクトの初期化が簡単なものでなければ、明示的な Init() メソッドを用意したり、オブジェクトの初期化が成功したかどうかを示すフラグをメンバに追加するなどを検討すること。 クラスがメンバ変数を定義していて他にコンストラクタがないのであれば、デフォルトコンストラクタを定義しなければならない。さもないとコンパイラが出来のわるいコンストラクタを定義してしまうだろう。 クラスオブジェクトを引数なしで new すると、デフォルトコンストラクタが呼び出される。 new[] したときにもデフォルトコンストラクタが呼び出される（配列の場合）。 デフォルトで「不可能な」値を持つように構造を初期化しておくと、デバッグがずっと簡単になる。 コードを書く人にとって余計な仕事になる。

もしクラスにメンバ変数を定義していて他にコンストラクタがないのであれば、デフォルトコンストラクタ（引数をとらないコンストラクタ）を定義しなければならない。そのようなオブジェクトはできるだけ、矛盾のない有効な内部状態になるように初期化するべきだ。

こうする理由は、もし他にコンストラクタがなくてデフォルトコンストラクタを定義していなければ、コンパイラがコンストラクタを生成してしまうためだ。コンパイラが生成したコンストラクタは、オブジェクトをうまく初期化してくれないかもしれない。

もしそのクラスが既存のクラスから継承したものであり、新しいメンバ変数を追加していないのであれば、デフォルトコンストラクタを持つ必要はない。

引数が1つのコンストラクタには、C++の explicit キーワードを付ける。 通常、引数が1つのコンストラクタは変換に使われる。例えば Foo::Foo(string name) が定義してあり、Foo を期待している関数に文字列を渡すと、コンストラクタが呼び出されて文字列を Foo に変換する。そして関数にはその Foo が渡されることになる。これは便利だ。しかし、変換によって暗黙のうちに新しいオブジェクトが生成されるのは、トラブルの原因にもなる。コンストラクタに explicit を宣言しておくと、暗黙に変換されるのを防ぐことができる。 望ましくない変換を避けることができる。 なし。

私たちは1つの引数をとるコンストラクタにはすべて、explicit を付けることにする。クラス定義において、引数が1つのコンストラクタの前には必ず explicit を付けること。 explicit Foo(string name);

ただしコピーコンストラクタは例外だ。こういうケースはめったにないが、explicit を付けるべきではないだろう。 他のクラスに対する透過的なラッパとして使うクラスもまた例外だ。 こういう例外はコメントにはっきりと明記しておくべきだ。

コピーコンストラクタはクラスをコピーする必要があるときだけ使う。たいていのクラスはコピーする必要はないはずだ。そのときには DISALLOW_COPY_AND_ASSIGN を使うべきだ。 コピーコンストラクタは、あるオブジェクトを新しいオブジェクトにコピーするときに使われる（特に、オブジェクトを値渡しするとき）。 コピーコンストラクタはオブジェクトのコピーを簡単にしてくれる。STLコンテナに格納するコンテンツはすべて、コピー可能であり代入可能である必要がある。 C++におけるオブジェクトの暗黙のコピーは、バグとパフォーマンス問題の温床になっている。またソースも読みにくくなる。どのオブジェクトが参照渡しではなく値渡しなのか、その結果、どこでオブジェクトに対する変更が反映されているのか、といった追跡がしにくくなるためだ。

たいていのクラスはコピー可能である必要はなく、コピーコンストラクタや代入オペレータを持つべきではない。残念ながら自分でこれらを宣言しておかないと、コンパイラ自身が生成して、それをパブリックにしてしまう。

定義のないコピーコンストラクタと代入オペレータのダミー宣言を、クラスの private: セクションに追加することを検討しよう。ダミールーチンをプライベートにしておくと、他のコードが使おうとしたときにコンパイルエラーになる。便利な DISALLOW_COPY_AND_ASSIGN マクロを使うことができる。

// コピーコンストラクタと=オペレータ関数を無効にするマクロ // これはクラスの private: 宣言の中で使うべきだ。 #define DISALLOW_COPY_AND_ASSIGN(TypeName) \ TypeName(const TypeName&); \ void operator=(const TypeName&)

そして class Foo の中では次のようにする。

class Foo { public: Foo(int f); ~Foo(); private: DISALLOW_COPY_AND_ASSIGN(Foo); };

ほとんどすべてのケースで、上に説明したような DISALLOW_COPY_AND_ASSIGN マクロを使うべきだ。コピー可能にする必要があるというクラスもまれにあるが、その場合はなぜそうする必要があるのかをクラスのヘッダファイルに明記しておくこと。それからコピーコンストラクタと代入オペレータを適切に定義するべきだ。operator= では、自己代入をチェックするのを忘れないこと。

クラスをコピー可能にしてSTLコンテナの値として使いたくなるかもしれない。実際にはほとんどの場合、STLコンテナにはオブジェクトを指すポインタを格納するべきだ。std::tr1::shared_ptr の利用を検討してもよい。

struct はデータを運ぶ受動的なオブジェクトだけに使う。それ以外はすべて class にする。

C++では、struct と class というキーワードはほとんど同じ動作になる。そこで私たちはそれぞれのキーワードに意味を持たせることにした。定義するデータの種類に合わせて、それぞれのキーワードを使い分けるべきだ。

struct はデータを運ぶ受動的なオブジェクトに使うべきだ。定数と関連付けてもよいが、データメンバの取得/設定以外の機能を持たせてはいけない。フィールドの取得/設定は、メソッド呼び出しではなくフィールドに直接アクセスすることにより実行する。メソッドは動作を提供するべきではなく、データメンバの設定にのみ使われるべきだ。つまりコンストラクタ、デストラクタ、Initialize()、Reset()、Validate() などだけにすること。

もっと機能が必要であれば class を使う方が適している。はっきりしなければ class にしておこう。

STLと一貫性を持たせるために、functor や traint には class ではなく struct を使っても構わない。

構造体とクラスのメンバ変数には異なる命名規則があることに注意すること。

継承よりもコンポジションの方がふさわしい場合が多い。継承を使うときには、public 継承にする。 ベースクラスからサブクラスを継承すると、親となるベースクラスに定義されているデータと操作の定義がすべてサブクラスにも含まれることになる。実際のところ、C++における継承の使い方には大きく二通りある。1つは実装の継承であり、実際のコードが子クラスによって継承される。そしてもう1つがインタフェースの継承であり、メソッド名だけが継承される。 実装の継承は既存の型を特殊化するものであり、ベースクラスのコードを再利用することでコードサイズを減らすことができる。継承はコンパイル時に宣言されるため、あなたもコンパイラも何が行われるか理解してエラーを見つけることができる。 インタフェースの継承はクラスに特定のAPIを公開させるために使うことができる。この場合にもコンパイラはエラーを検出することができる。クラスに必要とされているAPIメソッドが定義されていなければエラーになる。 実装の継承の場合、サブクラスの実装コードがベースクラスとサブクラスにまたがってしまうため、理解しにくくなる。またサブクラスでは非仮想関数を上書きすることができないため、サブクラスがその実装を変更することはできない。ベースクラスにデータメンバを定義することもできるが、こうするとベースクラスの物理的レイアウトが決まってしまう。

継承はすべて public にするべきだ。もしプライベート継承を使いたければ、代わりにベースクラスのインスタンスをメンバとして持たせるべきだ。

実装の継承を使いすぎてはいけない。実際のところコンポジションの方がふさわしい場合が多い。継承は "is-a" の関係があるときだけ使うようにしてみよう。 もし Bar は Foo の一種（a kind of）だと無理なく言えるのであれば、Bar は Foo のサブクラスにしてもよい。

protected を使うのは、サブクラスからアクセスされる必要があるかもしれないメンバ関数だけに制限しよう。データメンバは常にプライベートでなければならないことに注意しよう。

継承した仮想関数を再定義するときには、派生したクラスの宣言で virtual だと明示的に宣言すること。virtual を省略してしまうと、コードを読む人はその関数が仮想関数かどうかを確認するために、そのクラスのすべての先祖をチェックしなければいけなくなるためだ。

実際に実装の多重継承が役に立つことはまずない。ベースクラスのうち実装を持つクラスが高々1つであり、それ以外のクラスはすべて Interface というサフィックスのついた純粋なインタフェースクラスであるときのみ、多重継承を使っても構わない。 多重継承を使うとサブクラスは1つ以上のベースクラスを持つことができる。私たちは純粋なインタフェースとしてのベースクラスと実装を持つベースクラスを区別している。 実装の多重継承は単一継承よりもさらにコードの再利用ができることがある。（継承を参照すること）。 実際のところ、実装の多重継承が役に立つことはまずない。実装の多重継承が解決策になると思ったときには通常、別のもっと明確なきれいな解決策を見つけることができるはずだ。 最初の1つを除くすべてのスーパークラスが純粋なインタフェースであるときのみ、多重継承を使うことを許す。純粋なインタフェースであることを保証するために、これらは Interface というサフィックスで終わらなければならない。 Windows の場合には例外がある。 ある条件を満たしているクラスには、Interface というサフィックスを付けてもよい。これは必須ではない。

クラスが次の条件に当てはまるのであれば、それは純粋なインタフェースだ。

  • パブリックな純粋仮想（"= 0"）メソッドとスタティックメソッドしかない（ただし、デストラクタについては以下を参照すること）。
  • 非スタティックデータメンバはなくてもよい。
  • コンストラクタを定義する必要がない。もしコンストラクタがあるなら、それには引数がなくて protected でなければならない。
  • もしサブクラスであれば、これらの条件を満たすクラスから継承されており、そのクラス名には Interface サフィックスが付いている。

インタフェースクラスには純粋仮想メソッドが宣言されているため、直接インスタンス化することはできない。インタフェースの実装をすべて正しく確実に破棄するには、仮想デストラクタも宣言しておく必要がある（最初のルールの例外として、これは純粋仮想メソッドにすべきではない）。詳しくは、Stroustrup の The C++ Programming Language 第3版のセクション 12.4 を参照すること。

クラス名に Interface というサフィックスを付けておくと、実装を伴うメソッドや非スタティックデータメンバを追加してはいけないことが他人にもわかる。これは多重継承の場合には特に重要だ。 これに加えて、インタフェースというコンセプトはすでにJavaプログラマによく理解されている。 Interface というサフィックスを付けるとクラス名が長くなってしまい、読みにくくて理解しにくくなるおそれがある。また、インタフェースという属性はクライアントに公開するべきではない実装詳細のように思えてしまうかもしれない。 上の条件を満たすときのみ、クラスは Interface で終わってもよい。しかしその逆は要求しない。上の条件を満たすクラスは Interface で終わる必要はない。 まれな特殊な状況を除いて、オペレータをオーバーロードしてはいけない。 組み込み型のようにクラスを操作する + や / といったオペレータをクラスに定義することができる。 クラスが（int などの）組み込み型と同じように使えるので、コードは直感的にわかりやすくなる。オペレータのオーバーロードというのは、Equals() や Add() といった面白味のない関数に対して、遊び心のある名前を付けることだ。正しく動かすためにオペレータを定義しなければならないテンプレート関数もある。 オペレータをオーバーロードするとコードは直感的にわかりやすくなるが、欠点もいくつかある。
  • コストの高い操作なのに、コストの安い組み込み操作だと思わせてしまう。
  • オーバーロードしたオペレータを呼び出している場所を見つけるのは、とても難しくなる。== の呼び出しを探すよりも Equals() を探す方がはるかに簡単だ。
  • ポインタに対しても機能するオペレータもあるが、これはバグになりやすい。Foo + 4 がやることと、&Foo + 4 がやることは全く違う。コンパイラはどちらにも警告を出さないので、デバッグは非常に難しくなる。
オーバーロードには想定外の悪影響もある。例えば、operator& をオーバーロードしているクラスは前方宣言することができない。

一般的に、オペレータのオーバーロードを使ってはいけない。特に、代入オペレータ（operator=）はたちが悪いので避けるべきだ。オペレータのオーバーロードが必要であれば Equals() や CopyFrom() のような関数を定義すればよい。

しかし、オペレータのオーバーロードが必要になるケースもまれにある。それはテンプレートや "標準" C++クラス（ログのための operator<<(ostream&, const T&) など）と一緒に使うときだ。十分妥当な理由がある場合にはオペレータのオーバーロードを使ってもよいが、できるだけ避けるべきだ。具体的には、STLコンテナのキーとして使えるからといって operator== や operator< をオーバーロードしてはいけない。代わりに、コンテナを宣言するときには等価と比較の functor 型を作るべきだ。

STLアルゴリズムには operator== のオーバーロードが必要なものもある。その場合にはオーバーロードをしてもよいが、その理由を明記しておくこと。

コピーコンストラクタと関数のオーバーロードも参照すること。

データメンバはすべて private にして、必要に応じてアクセサ関数でアクセスできるようにする。通常は変数を foo_ に、アクセサ関数を foo() という形式にする。ミューテータ関数は set_foo() という形式にしてもよい。

アクセサの定義は通常、ヘッダファイルにインライン化しておく。

継承と関数名を参照すること。

クラスにおける宣言は、次に指定した順序にする。public: は private: の前に置く、メソッドはデータメンバ（変数）の前に置くなど。

クラスの定義は public: セクションから始めて、protected: セクション、private: セクションという順にするべきだ。セクションが空であれば省略する。

各セクション内では通常、次の順序で宣言するべきだ。

  • typedef と enum
  • 定数
  • コンストラクタ
  • デストラクタ
  • メソッド。スタティックメソッドも含む
  • データメンバ。スタティックデータメンバも含む

DISALLOW_COPY_AND_ASSIGN マクロは private: セクションの最後に入れるべきだ。つまりこれがクラス定義の最後になる。コピーコンストラクタを参照すること。

.cc ファイルにおけるメソッドの定義は、できるだけ宣言の順序と同じにするべきだ。

大きなメソッドの定義をインライン化してクラスの定義に入れてはいけない。インラインで定義してもよいのは、簡単もしくはパフォーマンスに影響を及ぼす、非常に簡潔なメソッドだけだ。詳しくはインライン関数を参照すること。

関数は小さく、ポイントを絞るのが望ましい。

私たちは長い関数の方がふさわしい場合があることを知っている。そのため、関数の長さには厳しい制限を設けていない。もし関数が約40行を超えるのであれば、プログラムの構造を変えずに関数を分割できないか考えること。

たとえ長い関数が完璧に動いていても、数か月後には誰かが変更して新しい動作を追加するかもしれない。これは見つけにくいバグを生むおそれがある。関数を短くシンプルにしておくと、他人が読みやすく変更しやすいコードになる。

コードをながめていると、長くて複雑な関数を見つけることがある。既存のコードを変更することを恐れてはいけない。もし扱いにくいと思ったり、エラーをデバックしにくいと思ったり、一部を別のところで使いたいと思ったら、その関数をもっと小さく分割して、管理できるようにしよう。

C++のコードをもっと堅牢にするために、私たちはいろいろな技や道具を使っている。ここでのやり方は、あなたが他のところで目にしてきたコードとは違っているかもしれない。

実際にポインタが必要になったときには scoped_ptr を使うのが望ましい。STLコンテナによってオブジェクトを保持する必要がある、といった特別な場合にだけ std::tr1::shared_ptr を使うべきだ。 auto_ptr は使うべきではない。

「スマート」ポインタはポインタのように機能するが、追加の意味がある。例えば scoped_ptr が破壊されるときには、ポインタが指しているオブジェクトも delete される。shared_ptr も同様だがリファレンスカウンタを実装しており、オブジェクトを指している最後のポインタだけがそのオブジェクトを delete する。

一般的には、明確なオーナーシップのあるコードを設計する方がよい。最も明確なオブジェクトのオーナーシップとは、ポインタを全く使わずにフィールドやローカル変数として直接オブジェクトを使うことだ。その対極にあるのがリファレンスカウントされたポインタであり、その定義からわかるように誰にも所有されていない。この場合の設計上の問題は、循環した参照やおかしな状況を作り出しやすく、決して delete されないオブジェクトができてしまうということだ。 また、値をコピーしたり割り当てるときには必ずアトミックな操作を実行するため、遅いという問題もある。

推奨するわけではないが、リファレンスカウントされたポインタが問題を解決するのに最もシンプルでエレガントな方法になる場合もある。

cpplint.py を使って、スタイルエラーを検出する。

cpplint.py は、ソースファイルを読み込んで、たくさんのスタイルエラーを検出してくれるツールだ。このツールは完全ではなく、誤検出も検出漏れもあるのだが、それでも役に立つ。誤検出があった場合には、その行の末尾に // NOLINT を入れると無視することができる。

プロジェクトで使っているツールからどのようにして cpplint.py を実行するのか、きちんと説明のあるプロジェクトもある。もしあなたが参加しているプロジェクトにそういう説明がなくても、個別に cpplint.py をダウンロードして使用することができる。

参照渡しのパラメータにはすべて、const を付けなければならない。 Cでは、関数が変数を変更する必要がある場合、パラメータにポインタを使わなければならない。例えば int foo(int *pval)。C++では、別の方法として、リファレンスパラメータを宣言することができる。int foo(int &val) パラメータをリファレンスとして定義すると、(*pval)++ といった見苦しいコードを避けることができる。コピーコンストラクタのような応用にも必要になる。ポインタと違って、リファンレンスは NULL が可能な値ではないことを明確にしてくれる。 リファレンスはまぎらわしい。構文は値と同じだが、意味はポインタと同じになる。

関数パラメータのリストでは、すべてのリファレンスに const を付けなければならない。

void Foo(const string &in, string *out);

実際のところ、入力引数は値か const リファレンスであり、出力引数はポインタであるというのは、Google code における非常に厳しい規約だ。入力パラメータに const ポインタを使っても構わないが、非const のリファレンスを使うことは許されない。

入力パラメータを const ポインタにしたくなるケースがある。引数がコピーされておらず、そのオブジェクトの生存期間に存在しなければならないことを強調したい場合だ。これは通常、コメントに明記しておくのが最適だ。bind2nd と mem_fun のようなSTLアダプタはリファレンスパラメータを許していない。そのため、この場合には、ポインタをパラメータとする関数も宣言しなければならない。

関数のオーバーロードを使うのは、同じ入力情報が異なる型で指定されている場合だけにする。デフォルト関数パラメータをシミュレートするために関数のオーバーロードを使ってはいけない。

const string& を引数とする関数を書き、それをconst char*を引数とする別の関数でオーバーロードしても構わない。

class MyClass { public: void Analyze(const string &text); void Analyze(const char *text, size_t textlen); }; オーバーロードを使うと引数が異なる関数に同じ名前を付けることができ、コードを直感的にわかりやすくする。これはテンプレート化されたコードに必要となることがある。また、Visitor を使うときにも便利だ。 関数のオーバーロードの使用を最小限にする理由の1つは、ある呼び出しがどの関数を呼び出しているのか理解しにくくなることだ。もう1つの理由は、もし継承しているクラスが関数をいくつかだけ上書きしているとき、たいていの人が継承の意味に混乱してしまうことだ。さらにライブラリのクライアントコードを読むのは、必要以上に難しくなる。これはデフォルト関数パラメータの使用に反対するのと同じ理由だ。 関数のオーバーロードをしたいのであれば、引数にちなんだ意味のある関数名にすることを検討すること。例えば、単なる Append() ではなく、AppendString() や AppendInt() とする。 デフォルト関数パラメータを使ってはいけない。 デフォルト値がたくさんある関数をよく見かけるが、デフォルトを上書きしたいときもある。デフォルトパラメータを使うと、めったにない例外のために関数をたくさん定義する必要がなくり、簡単になる。 APIを使っている既存のコードを見ることで、そのAPIの使い方が理解できることがよくある。 デフォルトパラメータは管理するのが難しい。以前のコードからコピー・アンド・ペーストしても、すべてのパラメータが見えているわけではないためだ。コードの断片をコピー・アンド・ペーストすると、デフォルト引数が新しいコードにとってふさわしくないときに大きな問題となる。 プログラマはよく理解せずにデフォルトを黙って受け入れてはいけない。APIと引数として渡している値についてよく検討させるため、すべての引数を明示的に指定すること。 可変長配列や alloca() を使ってはいけない。 可変長配列は自然な構文だ。可変長配列と alloca() はどちらも非常に効率がよい。 可変長配列と alloca は標準のC++の一部ではない。もっと問題なのは、スタック空間にデータ依存したメモリを割り当てて、発見困難なメモリの重ね書きバグを引き起こすおそれがあることだ。「ぼくのマシンだとうまく動くのに、現場だとなぜか落ちてしまう」。 scoped_ptr/scoped_array といった安全なアロケータを使うこと。 妥当な範囲であれば、friend クラスや friend 関数を使ってもよい。

フレンドは通常、同じファイルに定義しておくべきだ。こうしておくとコードを読む人は、クラスのプライベートメンバが使われている場所を見つけるのに、他のファイルの中まで見る必要はなくなる。friend がよく使われるのは FooBuilder クラスを Foo のフレンドにするというものだ。これによって、Foo の内部状態を全員に公開することなく、FooBuilder クラスは正しくオブジェクトを構築することができる。ユニットテストのクラスを、テスト対象となるクラスのフレンドにしておくと便利な場合もある。

フレンドはクラスのカプセル化の範囲を拡大するものだが、破ることはない。他のクラス1つだけからアクセスできるようにしたい場合には、メンバをパブリックにするよりもよい場合がある。しかし、たいていのクラスは単にパブリックメンバを介して別のクラスとやり取りするべきだ。

C++の例外を使わない。
  • 例外を使うと、アプリケーションのずっと高いレベルで、深く入れ子になった関数で発生した「起こり得ない」失敗を処理するかどうかを決定することができる。曖昧な間違いの元になるエラーコードの一覧といったものは不要になる。
  • 例外は最近の言語の多くで使われている。C++で例外を使うことは、PythonやJava、そしてみんながよく知っている C++とより一貫性を持たせることになる。
  • サードパーティ製 C++ ライブラリには例外を使っているものがある。例外を内部で見せなくしてしまうと、そういったライブラリとの統合が難しくなる。
  • 例外はコンストラクタが失敗したことを知る唯一の手段だ。ファクトリ関数や Init() メソッドによってこれをシミュレーションすることはできるが、それぞれヒープ割り当てや「不正な」状態が必要になる。
  • 例外はテストフレームワークにおいて本当に便利だ。
  • 既存の関数に throw 文を追加するときには、途中にある呼び出し元すべてを調査しなければならない。少なくとも基本的な例外の安全性を保証するか、例外を決して捕捉せずに結果としてプログラムが中断してしまうのを良しとしなければならない。例えば、f() が g() を呼び出し、g() が h() を呼び出し、h が f により捕捉される例外を投げるなら、g は気をつける必要がある。さもなければ適切にクリーンナップされないかもしれない。
  • さらに一般的には、例外を使うと、コードを見ただけで制御の流れを理解するのは難しくなる。関数は予期せぬ場所で戻ってきてしまうかもしれない。この結果、メンテナンスやデバッグは困難になる。例外の使い方や使ってもよい場所にルールを設けることで、このコストを最小化することもできる。しかし、開発者がそのことを知って理解するのには、さらにコストがかかる。
  • 例外の安全性には、RAIIと難しいコーディングプラクティスの両方が必要になる。正しい例外セーフなコードを簡単に書けるようにするには、コンピュータによるたくさんの支援が必要だ。さらに、コードを読む人がコールグラフ全体を理解しなければならないのを避けるためには、例外セーフなコードは不変状態を書き込むロジックを「コミット」フェーズに分離しなければならない。これはメリットでもありコストにもなる（おそらくコミットを分離するためにコードを分かりにくくしなければならない）。たとえ例外にそれほど価値がなくても、常にコストになってしまう。
  • 例外を有効にすると、生成されるバイナリが大きくなり、コンパイル時間が長くなり（おそらくわずか）、おそらくアドレス空間を圧迫することになる。
  • 例外を利用できるようにすると、開発者は適切でないときに例外を投げたり、安全でないときに例外から復帰しようとしてしまうおそれがある。例えば、不正なユーザ入力は例外を投げるべきではない。こうした制限を明文化しようとすると、スタイルガイドはもっと長くなってしまうだろう。

見ての通り、例外を使うメリットはコストを上回る。特に新規プロジェクトの場合にはそうだ。しかし、既存のコードに例外を導入しようとすると、依存しているコードすべてに影響が及んでしまう。もし例外が新しいオブジェクト以外にも影響を与えてしまうのであれば、その新規プロジェクトを例外のない既存のコードに組み込むのは問題になる。Googleの既存のC++コードの多くは、例外を処理するようにできていないので、例外を生成するような新しいコードを採用するのは、どちらかと言うと難しい。

Googleの既存のコードに例外に対する耐性がないことを考えると、例外を使うコストは新規プロジェクトの場合のコストよりもいくらか大きくなる。この変換プロセスには時間がかかり、問題になることが多い。私たちはエラーコードやアサーションといった例外の代わりに使える方法が、大きな障害になるとは思っていない。

例外を使うことへの反対意見は、賢明な、または、高潔な理由があるわけではなく、実践的なものだ。 Googleではオープンソースプロジェクトを使いたいのだが、例外を使っているプロジェクトを使うのは難しい。したがって、Googleオープンソースプロジェクトでも例外に対して反対意見を述べざるを得ない。 スクラッチからもう一度全部やり直さなければならないとしたら、おそらく考え方は違っていただろう。

Windowsのコードに関しては、このルールは例外だ（シャレじゃないよ）。

実行時型情報（RTTI）を使わない。 RTTIを使うと、プログラマは実行時にオブジェクトのC++クラスを問い合わせることができる。

これはユニットテストの場合に便利だ。例えばファクトリクラスのテストにおいて、新しく生成されたオブジェクトが期待通りの動的な型であることを確認するのに便利だ。

まれにテスト以外でも役に立つことがある。

実行時に型を問い合わせるということは、設計に問題があることが多い。実行時にオブジェクトの型を知る必要があるのなら、クラスの設計を再検討すべきだというサインかもしれない。

ユニットテスト以外で RTTI を使ってはいけない。オブジェクトのクラスによって異なる動作をするコードを書く必要があるのなら、別の方法で型を問い合わせることを検討すること。

仮想メソッドは、サブクラスの型により異なるパスでコードを実行するのにふさわしい方法だ。処理はそのオブジェクトの内部に置くことになる。

もし現在処理中のコード内ではなくオブジェクトの外部にその処理があるなら、Visitorデザインパターンのようなダブルディスパッチを使うことを検討しよう。ダブルディスパッチを使うと、オブジェクトの外部にあるものが組み込みの型システムを使ってクラスの型を決定することができる。

どうしてもこうしたアイデアを使うことができないと思うのなら、RTTIを使っても構わない。しかしその前にもう一度考えよう。:-) その後、もう一度考えよう。 RTTIに似たワークアラウンドを自前で実装してはいけない。RTTIに対する議論は、型タグを持つクラス階層のようなワークアラウンドにもほとんどそのまま当てはまる。

static_cast<>() といった、C++のキャストを使う。int y = (int)x; や int y = int(x); のような書式のキャストを使ってはいけない。 C++は、Cとは異なるキャストの仕組みを導入した。これはキャスト操作の種類を区別している。 Cのキャストには操作が不明確だという問題がある。 変換が行われることもあれば（例えば、(int)3.5）、キャストが行われることもある（例えば、(int)"hello"）。C++のキャストを使うとこれを避けることができる。さらにC++のキャストは、探すときにも目で見てわかりやすい。 構文が扱いにくい。

Cスタイルのキャストを使ってはいけない。代わりに、C++スタイルのキャストを使うこと。

  • 値の変換を行うようなCスタイルのキャストの代わりとして、あるいは、あるクラスからそのスーパークラスにポインタを明示的にアップキャストする必要があるときには、static_cast を使うこと。
  • const 修飾子（constを参照すること）を取り除くためには、const_cast を使うこと。
  • 整数やその他のポインタ型との安全ではないポインタ型の変換をするときには、reinterpret_cast を使うこと。何をやっているのかわかっていて、エイリアス問題を理解しているときだけ使うこと。
  • テストコード以外で dynamic_cast を使ってはいけない。 もしユニットテスト以外でこのように実行時に型情報を知る必要があるのであれば、おそらく設計上の欠陥がある。
ストリームはログ記録のためだけに使う。 ストリームは printf() や scanf() の代わりだ。 ストリームを使うと、プリントしているオブジェクトの型を知る必要がなくなる。書式文字列が引数リストとマッチしないという問題は起こらない。（しかし、gccであれば printf でも問題は起こらない）。ストリームには自動のコンストラクタとデストラクタがあり、対応するファイルのオープンとクローズを自動的にやってくれる。 ストリームを使って pread() のような動作を実現するのは難しい。 printf のようなハックを使わずにストリームを使って効率よくやるのは、不可能ではないが複雑な書式になることがある（具体的には、よく見かける文字列イディオム %.*s）。ストリームは国際化に役立つオペレータの並び換え（%1s ディレクティブ）をサポートしていない。

ログ記録インタフェースで必要とされる場合を除いて、ストリームは使わないこと。代わりに printf といったルーチンを使うこと。

ストリームの利用については賛否両論ある。しかしこの場合にも、例によって、一貫性を持つことがどんな議論にも勝る。コードにストリームを使ってはいけない。

この問題には長い議論があったので、もっと詳しく理由を説明しておこう。方法を1つにすることが原則を導くということを思い出そう。特定のI/Oの型を使うときにはいつでも、コードのどこであっても同じように見えるようにしたい。そのため、ストリームと read/writeなどや printf のどちらを使うのか、ユーザが決められるようにはしたくない。そうではなく、どちらか一つに決めておくべきだ。ただし、ログ記録については例外とした。これはかなり特殊なアプリケーションであり、歴史的な理由もあるためだ。

ストリームの提案者たちは、これら2つのうちからストリームが選ばれるのは疑う余地がないと主張していたが、実際には問題はそれほど明確なものではない。彼らが指摘するストリームの利点のすべてに対して、同じように欠点を挙げることができる。ストリームの最大の利点は、プリントするのにオブジェクトの型を知る必要がないことだ。これは疑う余地がない点だ。しかし、マイナス面もある。間違った型を使ってしまいやすく、コンパイラはそれを警告してくれない。ストリームを使うと、知らず知らずのうちにこのような間違いをしやすくなる。

cout << this; // アドレスをプリント cout << *this; // 内容をプリント

この場合、コンパイラはエラーを吐かない。<< がオーバーロードされているためだ。そのために私たちはオーバーロードを使うことを推奨していない。

printf は不細工で読みにくいという人もいるが、ストリームにも同じことが言えるだろう。次の2つのコードを見てみよう。どちらにも同じ typo がある。どちらの方が見つけやすいかな？

cerr << "Error connecting to '" << foo->bar()->hostname.first << ":" << foo->bar()->hostname.second << ": " << strerror(errno); fprintf(stderr, "Error connecting to '%s:%u: %s", foo->bar()->hostname.first, foo->bar()->hostname.second, strerror(errno));

その他にもいろいろと問題を挙げることができる。（あなたは「うまくラッパーを使えばもっとよくなる」と主張するかもしれない。しかしあるスキーマでそれが正しければ、他のスキーマでも正しいわけではないよね? それに目標は言語をもっと小さくすることであり、学習しなければならない仕組みをさらに追加することではない。）

どちらをとっても異なる利点と欠点があり、はっきりと優れた解決策というものはない。しかし、シンプルさの原則に従って、どちらか1つに決めなければならなかった。結局、多数決で printf + read/write になった。

イテレータやその他のテンプレートオブジェクトでは、インクリメント演算子およびデクリメント演算子を前置形式（++i）で使う。 変数をインクリメントしたり（++i や i++）、デクリメントしたり（--i や i--）して、その式の値を使わないとき、前置インクリメント（デクリメント）か後置インクリメント（デクリメント）のどちらを使うか選ばなければならない。 戻り値が無視されるとき、「前置」形式（++i）は「後置」形式（i++）よりも効率が悪くなることはなく、効率がよくなることが多い。後置インクリメント（またはデクリメント）の場合、i のコピー（これが式の値になる）を作る必要があるためだ。もしiがイテレータであったり、非スカラ型であれば、i をコピーするコストは高くなるだろう。 値が無視されるときにはこの2種類のインクリメントは同じような動作になるのに、どうして前置インクリメントだけにしないのか? Cでは式の値が使われないとき、具体形にはforでは、後置インクリメントを使うという伝統がある。後置インクリメントの方が読みやすいという人もいる。英語と同じように「主語」（i）が「動詞」（++）の前にあるためだ。 単純なスカラ（非オブジェクト）値には、どちらかを推奨する理由はなく、どちらを使っても構わない。イテレータやその他のテンプレート型には、前置インクリメントを使うこと。 理にかなっているときには必ず const を使うことを強く推奨する。 その変数が変更されないことを示すために、変数やパラメータの宣言の前に const キーワードを付けることができる（例えば const int foo）。その関数がクラスメンバ変数の状態を変更しないことを示すために、クラス関数に const という修飾子を付けることができる（例えば class Foo { int Bar(char c) const; };）。 変数がどのように使われるのか理解しやすくなる。コンパイラはさらに型チェックをすることができ、おそらくよりよいコードを生成してくれる。呼び出している関数が、変数を変更するのを制限しているかどうかがわかるので、プログラムの正確さを確かめるのに役立つ。マルチスレッドプログラムにおいて、どの関数がロックなしで安全に使えるのかを知るのにも役立つ。 const は感染する。もし関数に const 変数を渡すなら、その関数はそのプロトタイプに const を付けておかなければならない（あるいは、変数は const_cast をしなければならない）。これはライブラリ関数を呼び出すときには特に問題になるおそれがある。

const 変数、データメンバ、メソッド、引数はコンパイル時の型チェックのレベルを高めてくれる。できる限りすばやくエラーを検出することができる。 そのため私たちは、理にかなっているときにはいつも const を使うことを強く推奨する。

  • その関数がリファレンスやポインタで渡された引数を変更しないのであれば、引数に const を付けておくべきだ。
  • メソッドはできる限り const だと宣言しておくこと。アクセサはほぼ必ず const になるはずだ。もしデータメンバを変更せず、非constメソッドを呼び出すこともなく、データメンバに対する非constポインタや非constリファレンスを戻さないのであれば、そういうメソッドも const にすべきだ。
  • 生成後に変更する必要のないデータメンバは必ず const にしておくことを検討すること。

しかし、const を使おうとしすぎてもいけない。const int * const * const x; というコードはやりすぎだろう。たとえ x がどう const なのかを正確に記述していたとしてもね。 わかって本当に意味のあるところにポイントを絞ろう。この場合おそらく、const int** x で十分だ。

mutable キーワードを使っても構わないが、これはマルチスレッド環境では安全でない。スレッドセーフかどうかを最初に注意深く検討しておくべきだ。

const int* foo よりも int const *foo という形式を好む人もいる。const は必ずそれが説明しているオブジェクトの次にくるというルールには一貫性があり、読みやすくなると主張している。しかし、一貫性というのはこの場合には当てはまらない。「やりすぎてはいけない」という言葉によって、一貫性を持つ必要があるというのをほとんど無効にするためだ。 最初に const を置くと、ほぼ間違いなく読みやすくなる。「名詞」（int）の前に「形容詞」（const）を置くのが、英語と同じためだ。

const を最初に置くことを推奨するのだが、必須にはしていない。しかし、まわりのコードと一貫性を持たせること。

組み込みのC++整数型のうち、使ってもよいのは int だけだ。プログラムに別のサイズの変数が必要であれば、 <stdint.h> にある int16_t といった固定幅の型を使うこと。 C++は整数型のサイズを規定していない。通常、shortは16ビット、intは32ビット、longは32ビット、long longは64ビットになる。 宣言の不変性。 C++の整数型はコンパイラやアーキテクチャによって変わるかもしれない。

<stdint.h> には int16_t、uint32_t、int64_t といった型が定義されている。 short、unsigned long long の代わりに、常にこれらを使うべきだ。Cの整数型のうち、使うのは int だけにすべきだ。必要があれば size_t や ptrdiff_t といった標準型を使ってもよい。

私たちは int を非常によく使う。ループカウンタといった、それほど大きくならないのがわかっている整数のためだ。こういったものには昔からある int をそのまま使おう。int は少なくとも32ビットあると考えてもよいが、32ビット以上あるとは考えてはいけない。 もし64ビットの整数型が必要であれば、int64_t や uint64_t を使うこと。

「大きくなる」ことがわかっている整数には、int64_t を使うこと。

表現しているのが実際には数値ではなくビットパターンであったり、2の補数オーバーフローを定義する必要があるとき以外は、uint32_t といった unsigned 整数型を使うべきではない。特に、数値が負にならないと言うために unsigned 型を使ってはいけない。代わりにアサーションを使うこと。

教科書を書いている人のなかには、負にならない数値を表現するのに unsigned 型を使うのを推奨している人たちもいる。これは自己文書化を意図しているためだ。しかしCでは、実際に引き起こされるバグが文書化のメリットを上回ってしまう。考えてみよう。

for (unsigned int i = foo.Length()-1; i >= 0; --i) ...

このコードは止まらない! gccはこのバグに気づいて警告してくれるが、気づかないことも多い。同じように、signed と unsigned を比較するときにも、ひどいバグが引き起こされる場合がある。要するに、Cの型昇格の仕組みによって、unsigned 型は期待とは異なる動作になってしまうのだ。

そのため変数が負ではないことを示すにはアサーションを使うこと。unsigned 型を使ってはいけない。

コードは64ビットと32ビットの両方で動くようにしておくべきだ。プリント文、比較、構造体のアラインメントの問題を忘れないようにすること。

  • printf() の指定子には、32ビットシステムと64ビットシステムとの間で移植性があるかはっきりしていないものがある。C99は移植性のある書式指定子をいくつか定義している。残念ながらMSVC 7.1はこうした指定子のいくつかを理解できず、標準は少し欠けている。そのため場合によっては、自分で不細工なバージョンを定義する必要がある（標準のインクルードファイル inttypes.h のスタイルで）。

    // size_t のための printf マクロ。inttypes.h のスタイルで。 #ifdef _LP64 #define __PRIS_PREFIX "z" #else #define __PRIS_PREFIX #endif // これらのマクロを32/64ビットの両方で正しく動かすために、 // 次のように、printf 書式文字列では % の後に入れること。 // size_t size = records.size(); // printf("%"PRIuS"\n", size); #define PRIdS __PRIS_PREFIX "d" #define PRIxS __PRIS_PREFIX "x" #define PRIuS __PRIS_PREFIX "u" #define PRIXS __PRIS_PREFIX "X" #define PRIoS __PRIS_PREFIX "o"
    型 使ってはいけない 使ってもいい 注意
    void * （あるいは任意のポインタ） %lx %p
    int64_t %qd, %lld %"PRId64"
    uint64_t %qu, %llu, %llx %"PRIu64", %"PRIx64"
    size_t %u %"PRIuS", %"PRIxS" C99では %zu
    ptrdiff_t %d %"PRIdS" C99では %zd

    PRI* マクロは、コンパイラによって連結された独立した文字列に展開されることに注意すること。そのため定数ではない書式文字列を使う場合には、その名前ではなくマクロの値を書式に入れておく必要がある。PRI* マクロを使うときには、% の後に長さ指定子などを入れておくと必ずそうすることができる。例えば、printf("x = %30"PRIuS"\n", x) は32ビットLinuxでは printf("x = %30" "u" "\n", x)に展開され、コンパイラはprintf("x = %30u\n", x) として処理することになる。

  • sizeof(void *) != sizeof(int) であることを覚えておこう。もしポインタサイズの整数が必要なら intptr_t を使うこと。
  • 構造体のアラインメントにも注意する必要があるかもしれない。特に、構造体をディスク上に格納する場合には必要になる。クラスや構造体に int64_t/uint64_t のメンバがあるときには、64ビットシステムにおけるアラインメントはデフォルトで8バイトになる。32ビットと64ビットコードの間でディスク上で共有されている構造体などがあれば、両方のアーキテクチャで同じになるようパックしてあるか確認する必要があるだろう。 たいていのコンパイラには構造体のアラインメントを変える方法がある。例えば gcc の場合、__attribute__((packed)) を使うことができる。MSVCの場合には、#pragma pack() と __declspec(align()) を使うことができる。
  • 64ビット定数を用意する必要があるときには、LL や ULL というサフィックスを使うこと。例えば次のようになる。 int64_t my_value = 0x123456789LL; uint64_t my_mask = 3ULL << 48;
  • 本当に32ビットシステムと64ビットシステムで異なるコードが必要であれば、コードを分岐させるのに #ifdef _LP64 を使うこと。（ただし、できればこれを避けて、変更が局所的になるようにすること）
マクロには十分注意する。マクロを使うよりもインライン関数や enum、const 変数を使う方が望ましい。

マクロを使うということは、あなたが見ているコードとコンパイラが見ているコードは同じではなくなるということだ。これは予期せぬ動作を引き起こすことがある。特に、マクロがグローバルスコープにあるときには起こりやすい。

幸運にも、C++ではCほどマクロは必要にならない。パフォーマンスに影響を及ぼすコードをインライン化するためには、マクロではなくインライン関数を使うこと。定数を格納するためには、マクロではなく const 変数を使うこと。長い変数名を省略するためには、マクロではなくリファレンスを使うこと。コードを条件付きコンパイルするためには、マクロではなく、いや、そもそもそんなことをしてはいけない（もちろん、ヘッダファイルの二重インクルードを防ぐための #define ガードは除く）。そんなことをするとテストがとても難しくなる。

こうした他のやり方ではできない場合には、マクロを使っても構わない。コードベース、特に低レベルのライブラリの中では見かけることがある。また、特別な機能には、言語によってはうまく利用できないものもある（文字列化、連結など）。しかしマクロを使う前には、マクロを使わないで同じ結果を達成する方法がないか注意深く検討すること。

次に示す利用パターンに従うと、マクロを使ったときの問題の多くを避けることができるだろう。マクロを使うときにはできるだけ以下に従うこと。

  • .h ファイルにマクロを定義してはいけない。
  • 使う直前に #define マクロを置き、使った直後に #undef すること。
  • 既存のマクロを自分のもので置き換えたいからといって、既存のマクロを #undef してはいけない。代わりに一意な名前を持つマクロにすること。
  • アンバランスなC++構造体を拡張するためにマクロを使ってはいけない。さもなければ、少なくともその動作についてしっかり明記しておくこと。
整数には 0 を、実数には 0.0 を、ポインタには NULL を、文字には '\0' を使う。

整数には 0 を使い、実数には 0.0 を使うこと。これには賛否両論ある。

ポインタ（アドレス値）には、0 と NULL という選択肢がある。 Bjarne Stroustrup は簡素な 0 の方を好んでいる。私たちは NULL の方が好きだ。この方がポインタらしく見えるためだ。実際のところ、C++コンパイラには gcc 4.1.0 のように、役に立つ警告ができるよう NULL に特別な定義付けをしているものもある。具体的に言うと、sizeof(NULL) は sizeof(0) と等しくない、という警告を出してくれる。

文字には '\0' を使うこと。 これは型も正しく、コードも読みやすくなる。

できる限り sizeof(型) ではなく sizeof(変数名) を使う。

sizeof(変数名) を使うこと。こうしておくと、もし変数の型を変更してもうまく更新されるためだ。 sizeof(型) の方が理にかなっている場合もあるが、一般的には避けるべきだ。変数の型を変更すると一致しなくなるおそれがある。

Struct data; memset(&data, 0, sizeof(data)); memset(&data, 0, sizeof(Struct));

Boostライブラリ群のうち許可されているライブラリだけを使う。 Boostライブラリコレクションは人気がある、よくレビューされたフリーのオープンソースC++ライブラリ集だ。 Boostのコードは一般的に非常に高品質で、移植性がよく、C++標準ライブラリにあるたくさんの大きなギャップを、type traints（型特性）や、よりよい binder やスマートポインタといったもので埋めてくれる。これはまた、標準ライブラリに対するTR1拡張の実装も提供している。 Boostライブラリには、読みやすさを妨げるようなコーディングプラクティスを促すものもある。メタプログラミングや先進的なテンプレートテクニック、行き過ぎた「関数」スタイルのプログラミングといったものだ。 コードを読んでメンテナンスをするコントリビュータ（貢献者）全員にとって読みやすいようにするため、私たちはBoost機能のサブセットだけ、使うことを許している。現在のところ、次のライブラリが許可されている。
  • Compressed Pair（boost/compressed_pair.hpp）
  • Pointer Container（boost/ptr_container）ただしシリアライゼーションを除く。
  • Array（boost/array.hpp）
  • Boost Graph Library（BGL）（boost/graph）ただしシリアライゼーションを除く。
  • Property Map（boost/property_map.hpp）
  • Iterator の一部。次のイテレータの定義に対応するもの。 boost/iterator/iterator_adaptor.hpp、 boost/iterator/iterator_facade.hpp、 boost/function_output_iterator.hpp
私たちはこの他のBoost機能をリストに追加することを積極的に検討している。そのため、このルールは将来緩和されるかもしれない。

一貫性を保つ上で最も重要なルールは命名に関するものだ。命名スタイルがあると、名付けられたものが何であるのか、型や変数、関数、定数、マクロといったことがすぐにわかるようになる。宣言を探す必要はなくなる。頭の中のパターンマッチングエンジンは命名規則をとても頼りにしている。

命名規則というものはかなりいい加減なものだが、個人の好みよりも一貫性を持つことの方が重要だと考えている。だから、理にかなっていると感じようが感じまいが、ルールはルールだ。

関数名、変数名、ファイル名はわかりやすいものにするべきだ。省略は避けること。型や変数は名詞に、関数は「命令」の動詞にするべきだ。

無理のない範囲で、できるだけわかりやすい名前にすること。スペースを節約しようとしてはいけない。新しくコードを読む人がすぐに理解できるようすることの方が、はるかに重要だ。よい名前の例を以下に挙げる。

int num_errors; // よい。 int num_completed_connections; // よい。

よくない名前とは、曖昧な省略や意味のないいい加減な言葉を使うことだ。

int n; // よくない - 意味がない。 int nerr; // よくない - 曖昧な略語。 int n_comp_conns; // よくない - 曖昧な略語。

型と変数の名前は通常、名詞にするべきだ。例えば、FileOpener、num_errors。

関数名は通常、命令的なものにするべきだ（つまりコマンドにするべきだ）。例えば OpenFile()、set_num_errors()。アクセサは例外であって、アクセスする変数と同じ名前にしておくこと。関数名で詳しく説明している。

プロジェクト外で極めてよく知られた言葉でない限り、略語を使ってはいけない。例:

// よい // これらは省略のない適切な名前だ。 int num_dns_connections; // たいていの人は "DNS" が何を示しているのか知っている。 int price_count_reader; // OK、price count. 意味がわかる。 // よくない! // こうした略語は小さなグループ外では混乱したり、曖昧になるおそれがある。 int wgc_connections; // これが何を示しているのかわかるのはあなたのグループだけだ。 int pc_reader; // いろいろなものが "pc" という略語にされている。

文字を削って短縮してはいけない。

int error_count; // よい。 int error_cnt; // よくない。 ファイル名はすべて小文字にするべきだ。アンダースコア（_）やダッシュ（-）が含まれていてもよい。プロジェクトで使っている規約に従うこと。

許されるファイル名の例。

my_useful_class.cc
my-useful-class.cc
myusefulclass.cc

C++ファイルは .cc で終わるべきであり、ヘッダファイルは .h で終わるべきだ。

db.h のようにすでに/usr/includeに存在するファイル名を使ってはいけない。

一般に、ファイル名は非常に具体的なものにすること。例えば、logs.h ではなく http_server_logs.h とすること。例えば、FooBar というクラスを定義するときには、foo_bar.h と foo_bar.cc というファイルのペアを使うことが非常に多い。

インライン関数は .h ファイルに入れなければならない。インライン関数が非常に簡潔であれば、.h ファイルの中に直接書いておくべきだ。しかし、インライン関数にたくさんのコードが含まれるのであれば、-inl.h で終わる別のファイルに入れてもよい。インラインコードがたくさんあるクラスは、3つのファイルから構成されることになる。

url_table.h // クラスの宣言 url_table.cc // クラスの定義 url_table-inl.h // たくさんのコードを含むインライン関数

-inl.h ファイルのセクションも参照すること。

型名は大文字で始めて、単語の頭文字を大文字にする。アンダースコアは使わない。MyExcitingClass、MyExcitingEnumなどとする。

あらゆる型、— クラス、構造体、typedef、enum — の名前には同じ命名規約を使う。型名は大文字で始めて、単語の先頭を大文字にするべきだ。アンダースコアは使わない。例:

// クラスと構造体 class UrlTable { ... class UrlTableTester { ... struct UrlTableProperties { ... // typedefs typedef hash_map<UrlTableProperties *, string> PropertiesMap; // enums enum UrlTableErrors { ... 変数名はすべて小文字にして、単語と単語の間にはアンダースコアを入れる。クラスメンバ変数はアンダースコアで終わるようにする。例えば、my_exciting_local_variable、my_exciting_member_variable_。

例:

string table_name; // OK - アンダースコアを使っている。 string tablename; // OK - すべて小文字だ。 string tableName; // よくない - 大文字小文字が混ざっている。

データメンバ（インスタンス変数やメンバ変数とも呼ばれる）は通常の変数名と同様に、アンダースコアを含む小文字にする。ただし、必ずアンダースコアで終わること。

string table_name_; // OK - アンダースコアで終わる string tablename_; // OK.

構造体のデータメンバは、クラスのデータメンバにおける末尾のアンダースコアを除いて、通常の変数と同様に命名すべきだ。

struct UrlTableProperties { string name; int num_entries; }

構造体とクラスをどう使い分けるかについては、構造体 対 クラスを参照しよう。

グローバル変数については特別な決まりはない。グローバル変数はめったに使うべきではないが、もし使うのであれば g_ などのプレフィックスを付けてローカル変数と区別しやすくすることを検討しよう。

kで始まり、大文字小文字で続ける。kDaysInAWeek

コンパイル時定数は、それがローカルであろうとグローバルであろうと、クラスの一部としてであろうと、どう宣言されていても、他の変数とは全然違う命名規約に従うこと。k の後に単語の先頭を大文字にして続けること。

const int kDaysInAWeek = 7; 通常の関数は大文字小文字の組み合わせにする。アクセサやミューテータは変数名と一致させる。 MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable()

関数名は大文字で始めて、単語の先頭を大文字にするべきだ。アンダースコアは使わない。

AddTableEntry() DeleteUrl()

アクセサとミューテータ（get/set 関数）は取得および設定しようとする変数名と一致させるべきだ。以下は、num_entries_ というインスタンス変数を持つクラスの一部を示している。

class MyClass { public: ... int num_entries() const { return num_entries_; } void set_num_entries(int num_entries) { num_entries_ = num_entries; } private: int num_entries_; };

非常に簡潔なインライン関数には小文字を使っても構わない。例えば、ループの中でその関数を読んでも値をキャッシュしないような非常に簡単なものであれば、小文字で命名してもよい。

名前空間名はすべて小文字にし、プロジェクト名と可能ならディレクトリ構造に基づいた名前にする。例えば google_awesome_project。

名前空間とその命名については、名前空間を参照しよう。

列挙子の名前は、定数 か マクロ のようにするべきだ。つまり、kEnumName か ENUM_NAME 。

できれば、個々の列挙子は 定数 のようにするべきだ。しかし、マクロ のようであっても構わない。列挙型名 UrlTableErrors（そして、AlternateUrlTableErrors）は型であり、これは大文字と小文字を組み合わせた名前にする。

enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, kErrorMalformedInput, }; enum AlternateUrlTableErrors { OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2, };

2009年1月までは、enum値は マクロ のように命名するというスタイルだった。これはenum値とマクロの名前の衝突という問題を引き起こした。そのため、定数スタイルの命名の方がよいという変更をした。新しいコードはできるだけ定数スタイルの命名にするべきだ。しかし、古い命名が実際にコンパイル時の問題を引き起していないのであれば、古いコードを定数スタイルの命名に変更する理由はない。

本当にマクロを定義しようとは思ってないよね？ もしマクロを定義するなら、このようにする。 MY_MACRO_THAT_SCARES_SMALL_CHILDREN

マクロの説明を参照しよう。一般的にマクロは使うべきではない。しかしどうしても必要であれば、enum値の名前のように、大文字とアンダースコアだけを使った名前にするべきだ。

#define ROUND(x) ... #define PI_ROUNDED 3.0 もしCやC++に既にあるものに似ているものに名前を付けようとしているなら、既存の命名規約に従っても構わない。

bigopen()
関数名。open() の形に従う
uint
typedef
bigpos
struct や class。 pos の形に従う。
sparse_hash_map
STLに似たエンティティ: STL の命名規約に従う。
LONGLONG_MAX
定数。INT_MAX と同様。

コメントを書くのは苦痛だが、コードを読みやすくしておくためには不可欠だ。以下のルールは、どこにどんなコメントを書くべきかを説明したものだ。 しかし忘れないでほしい。コメントはとても重要だが、最高のコードとは自己文書化されたコードだ。曖昧な名前を付けてコメントで説明しようとするよりも、型や変数に理にかなった名前を付けておく方がはるかによい。

コメントを書くときには、コードを読む人のために書こう。つまりコードを理解する必要のある次のコントリビュータ（貢献者）のためだ。親切になろう — 次のコントリビュータ（貢献者）というのはあなた自身のことかもしれないよ!

// か /* */ か、どちらかの構文を、一貫性を持って使う。

// か /* */ のどちらの構文を使ってもよい。しかし、// の方がかなりよくみかける。 どのようにコメントをするのか、どんなスタイルでどこにコメントするのか、一貫性を持たせること。

各ファイルはコピーライト宣言から始める。その後に、ファイル内容の説明を書く。

すべてのファイルには、以下の項目をこの順序で入れておくべきだ。

  • コピーライトに関する文（例えば、 Copyright 2008 Google Inc.）
  • ライセンスの決まり文句。 そのプロジェクトで使うライセンスに合わせて選ぶこと。（例えば、 Apache 2.0, BSD, LGPL, GPL）
  • ファイルの原作者がわかるような作者に関する行

もともと他人が書いたファイルに大きな変更をしたときには、作者のところに自分の名前を追加しよう。これは、他のコントリビュータ（貢献者）がそのファイルについて質問をしたり、問い合わせ先を知る必要があるときに、とても役に立つ。

各ファイルの先頭（作者に関する行の下）には、ファイルの内容について書いたコメントを入れておくべきだ。

.h ファイルでは通常 、そのファイルで宣言しているクラスがどんなもので、どのように使うのか、概略を説明する。.cc ファイルには詳細実装やトリッキーなアルゴリズムの解説について詳しい情報を入れておくべきだ。もし.h を読む人にとって実装詳細やアルゴリズムの解説が役に立つと思うのであれば、.h に入れておいても構わない。ただし .cc ファイルには、ドキュメントが .h にあることを明記しておくこと。

.h と .cc にあるコメントをコピーしてはいけない。コピーするとコメントが枝分かれしてしまうためだ。

クラス定義にはすべて、そのクラスが何のためにあり、どのように使われるべきかを説明するコメントを付けておくべきだ。 // Iterates over the contents of a GargantuanTable. Sample usage: // (GargantuanTable の中身をイテレートする。使い方の例) // GargantuanTable_Iterator* iter = table->NewIterator(); // for (iter->Seek("foo"); !iter->done(); iter->Next()) { // process(iter->key(), iter->value()); // } // delete iter; class GargantuanTable_Iterator { ... };

クラスの詳細について、すでにファイルの先頭で説明しているのであれば、"See comment at top of file for a complete description"（「詳しくはファイル先頭のコメントを参照」）と記載しても構わないが、必ず何らかのコメントを入れておくこと。

もしクラスが想定している同期があるのであれば、それについて書いておこう。もしクラスのインスタンスが複数のスレッドからアクセスされる可能性があるのなら、マルチスレッドの利用に関するルールや不変条件が明記してあるか、十分注意すること。

関数宣言のコメントには関数の使い方を書く。関数定義のコメントには処理内容を書く。

すべての関数宣言には、その関数が何をするもので、どうやって使うのかを説明するコメントをその関数の直前に入れておくべきだ。このコメントは命令調（「ファイルをオープンしろ」）ではなく説明調（「ファイルをオープンする」）にしておくべきだ。コメントは関数について説明するものであって、関数が何をしているのかを説明するものではない。一般的に宣言のコメントは、関数があるタスクをどのようにやっているかを説明するものではない。これは関数宣言ではなく関数定義のコメントに入れておくべきだ。

関数宣言のコメントで言及すべきもの。

  • 入出力が何であるか。
  • クラスメンバ関数に関して、そのオブジェクトがメソッドを呼び出している期間以上にリファレンス引数を覚えているかどうか、それらを解放するのかしないのか。
  • 呼び出し側が解放しなければならないメモリをその関数が割り当てているかどうか
  • いずれかの引数が NULL になるおそれがあるかどうか。
  • 関数の使い方によってパフォーマンスに影響があるかどうか。
  • 関数がリエントラントかどうか。想定している同期は何か？

以下に例を挙げよう。

// Returns an iterator for this table. It is the client's // responsibility to delete the iterator when it is done with it, // and it must not use the iterator once the GargantuanTable object // on which the iterator was created has been deleted. // // The iterator is initially positioned at the beginning of the table. // // This method is equivalent to: // Iterator* iter = table->NewIterator(); // iter->Seek(""); // return iter; // If you are going to immediately seek to another place in the // returned iterator, it will be faster to use NewIterator() // and avoid the extra seek. Iterator* GetIterator() const;

不必要に冗長にしたり、完璧に明確に記述しようとしてはいけない。以下のように「さもなければ false を返す」と書く必要はない。これは書かなくてもわかることだ。

// Returns true if the table cannot hold any more entries. // （テーブルがこれ以上エントリを保持できないとき true を返す。） bool IsTableFull();

コンストラクタとデストラクタにコメントを入れるときには、コードを読む人は何のコンストラクタとデストラクタであるかわかっていることを覚えておこう。「オブジェクトを破棄する」のようなコメントには意味がない。コンストラクタがその引数をどう処理するのか（例えばそれらにポインタのオーナーシップがあるなら）、デストラクタは何を解放するのか、といったことをコメントに入れよう。ささいなことであれば、コメントに入れなくてもいい。デストラクタにヘッダコメントがないことはかなりよくあることだ。

それぞれの関数定義には、その関数がやることと、トリッキーなことをしているところを説明するコメントを入れておくべきだ。例えば、関数定義には、使っているコーディングテクニックを説明するコメントを入れておいたり、処理ステップの概要を説明したり、なぜ別の案ではなくその実装方法を選んだのかを説明しよう。例えば、なぜ関数の前半でロックを取得しなければならず、後半はその必要がないのか説明するとよい。

.h やどこかにある関数宣言のコメントを繰り返すだけではいけないことに注意しよう。その関数が何であるかを短く要約するのにはいいが、コメントのポイントはどのようにそれをやるのかにあるべきだ。

一般的に、変数名は説明的なものにして、その変数が何のために使われるのかわかるようにすべきだ。さらにコメントが必要になる場合もある。

それぞれのクラスデータメンバには（インスタンス変数やメンバ変数と呼ばれることがある）、何のために使われるのかを説明するコメントを入れておくべきだ。もし変数が NULL や -1 といった特別な意味のある値を番人として扱うのであれば、そのことを明記しておこう。例:

private: // Keeps track of the total number of entries in the table. // Used to ensure we do not go over the limit. -1 means // that we don't yet know how many entries the table has. int num_total_entries_;

データメンバに関して、グローバル変数にはすべて、それが何であり何のために使われるのかを説明するコメントを入れておくべきだ。例:

// The total number of tests cases that we run through in this regression test. // （回帰テストで実行するテストケースの総数） const int kNumTestCases = 6; 実装においては、コードのトリッキーなところ、不明瞭なところ、興味深いところ、重要なところにコメントを入れておくべきだ。

トリッキーまたは複雑なコードブロックには、その直前にコメントを入れておくべきだ。例:

// Divide result by two, taking into account that x // contains the carry from the add. for (int i = 0; i < result->size(); i++) { x = (x << 8) + (*result)[i]; (*result)[i] = x >> 1; x &= 1; }

わかりにくい行にはその行の末尾にコメントを入れておくべきだ。そして行末コメントは、コードからスペース2つ空けておくべきだ。例:

// If we have enough memory, mmap the data portion too. // もしメモリが十分あれば、データ部分も mmap する。 mmap_budget = max<int64>(0, mmap_budget - index_->length()); if (mmap_budget >= data_size_ && !MmapData(mmap_chunk_bytes, mlock)) return; // Error already logged. （エラーはログ記録される。）

そのコードが何をしているのかを説明しているコメントと、関数が戻るときにはエラーがすでにログ記録されていることについて述べているコメントがあることに注意しよう。

もしコメントが複数行にわたるのであれば、一列に並べると読みやすくなることが多い。

DoSomething(); // Comment here so the comments line up. DoSomethingElseThatIsLonger(); // Comment here so there are two spaces between // the code and the comment. { // One space before comment when opening a new scope is allowed, // thus the comment lines up with the following comments and code. DoSomethingElse(); // Two spaces before line comments normally. }

関数に NULL や boolean、リテラル整数値を渡すときには、それが何であるかをコメントに書いたり、定数を使って自己文書化したコードにすることを検討すべきだ。例えば、以下を比べてみよう。

bool success = CalculateSomething(interesting_value, 10, false, NULL); // これらの引数は何だろう??

これに対して次のようにする:

bool success = CalculateSomething(interesting_value, 10, // Default base value.（デフォルトのベース値。） false, // Not the first time we're calling this.（これを呼び出すのは初めてではない。） NULL); // No callback.（コールバックなし。）

あるいは代わりに、定数や自己文書化した変数を使ってもよい:

const int kDefaultBaseValue = 10; const bool kFirstTimeCalling = false; Callback *null_callback = NULL; bool success = CalculateSomething(interesting_value, kDefaultBaseValue, kFirstTimeCalling, null_callback);

コードそのものを説明してはいけない。たとえあなたが何をやろうとしているのか知らなくても、あなたよりC++のことをよく知っている人がコードを読んでいるのだと考えよう。

// Now go through the b array and make sure that if i occurs, // the next element is i+1. ... // Geez. What a useless comment. 句読点、綴り、文法に注意しよう。達筆なコメントの方が読みやすい。

コメントは通常、1つの完結した文章として書くべきだ。適切に大文字を使い、末尾にはピリオドを付けること。コードの末尾に入れるときのように、コメントが短くなるほど形式が失われることがある。でもスタイルには一貫性を持つべきだ。完結した文章の方が読みやすいし、完成したコメントは未完成の思い付きでないことをある程度保障してくれる。

コードレビュアーから、セミコロンを使うべきなのにカンマを使っている、と指摘されるとイライラするが、ソースコードの明確さ、読みやすさを高いレベルで維持することは極めて重要だ。句読点や綴り、文法が適切であることは、それを実現する助けになる。

TODO コメントは、一時的なものや、短期的な解決策、その場しのぎの不完全なところに使う。

TODO には、すべて大文字からなる TODO という単語を使い、その後に名前やメールアドレスといった識別子を括弧で囲んだものを入れておくべきだ。コロンはあってもなくてもよい。これは TODO の書式に一貫性を持たせて、そのコメントを追加した人を探せるようにするためだ（その人に頼めばさらに詳細を教えてもらえる）。TODO は書いた人が自分で修正することを約束するものではない。

// TODO(kl@gmail.com): Use a "*" here for concatenation operator. // TODO(Zeke) change this to use relations.

もし TODO が「将来の日付に何かする」という形式であれば、具体的な日付が入っているか（「2005年11月までに修正」）、もしくは具体的なイベントが入っているか（「すべてのクライアントがXMLレスポンスを処理できるようになったらこのコードを削除すること」）を確認しよう。

コーディングスタイルや書式というものはかなりいい加減なものだが、みんなが同じスタイルを使うとプロジェクトはわかりやすくなる。書式のルールのすべてには合意してくれない人もいるだろう。慣れるまで時間がかかるルールもあるだろう。それでも、プロジェクトのコントリビュータ全員がスタイルルールに従うことは重要なことだ。こうすることで、全員のコードは読みやすく理解しやすいものになる。

コードを正しい書式にするのを助けるために、私たちは Emacs用の設定ファイル を作った。

コードにおいて、テキスト1行の長さは、長くても80文字にすべきだ。

このルールには賛否両論あると思うが、すでに既存のコードのほとんどがこれを守っているし、私たちは一貫性が重要だと思っている。

このルールに賛成している人は、ウィンドウをリサイズさせるのは失礼なことで、これ以上長くする必要はないと言う。コーディングのために複数のウィンドウを並べて使って、これ以上ウィンドウを広げる余地がないという人もいる。みんな最大ウィンドウサイズを想定した作業環境を設定している。80カラムが昔からの標準だ。どうしてこれを変える必要があるんだい？ 変更を支持している人は、1行を長くするとコードがもっと読みやすくなると言う。80カラムという制限は時代遅れで、1960年代のメインフレームに後戻りするようなものだ。最新機器はもっとスクリーンが広くて、簡単にもっと長い行を表示することができる。

80文字を最大とする。

例外: もしコメント行に80文字を超えるコマンド例やURL文字列が含まれるのなら、カット・アンド・ペーストが簡単にできるよう、その行は80文字を超えても構わない。

例外: 80カラムを超える長いパスを含む #include 文。こんなものが必要にならないようにしよう。

例外: ヘッダガードは最大長を超えても気にする必要はない。

非ASCII文字はめったに使ってはいけない。もし使うときには UTF-8フォーマットを使わなければならない。

ユーザに見せるテキストをソースにハードコードしてはいけない。たとえ英語だとしてもだ。そのため、非ASCII文字を使うことはほとんどないはずだ。そういったテキストをコードに入れる方がよい場合もある。例えば、外部からのデータファイルをパースするコードであれば、データファイルのデリミタとして使う非ASCII文字をハードコードしておく方がよいかもしれない。もっとよくあるのは、ユニットテストのコード（ローカライズの必要はない）に特定の非ASCII文字が含まれている場合だ。このときには UTF-8 を使うべきだ。UTF-8であれば、ASCII以外の文字を処理できるたいていのツールで解釈可能だ。 Hexエンコーディングを使っても構わない。これを使うと読みやすくなることがある。例えば、"\xEF\xBB\xBF" は Unicode の ゼロ幅改行なし空白文字であり、ソースコードにそのままUTF-8として入れても見ることができない。

スペースだけを使う。インデントはスペース2つにする。

インデントにはスペースを使う。コードにはタブを使ってはいけない。 タブキーを押したときにはスペースが入力されるように、エディタを設定しておこう。

戻り値の型は関数名と同じ行に書く。1行に収まるなら、パラメータも同じ行に書く。

関数は次のようになる:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) { DoSomething(); ... }

長すぎて1行に収まらないときには、次のようにする:

ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2, Type par_name3) { DoSomething(); ... }

最初のパラメータでさえも1行に収まらないのであれば、次のようにする:

ReturnType LongClassName::ReallyReallyReallyLongFunctionName( Type par_name1, // スペース4つでインデント Type par_name2, Type par_name3) { DoSomething(); // スペース2つでインデント ... }

注意すべきポイント:

  • 戻り値の型はいつも関数名と同じ行に書くこと。
  • 開き括弧（'('）はいつも関数名と同じ行に書くこと。
  • 関数名と開き括弧の間にはスペースを入れてはいけない。
  • 括弧とパラメータの間にはスペースを入れてはいけない。
  • 開き中括弧（'{'）は必ず最後のパラメータと同じ行の末尾に書くこと。
  • 閉じ中括弧（'}'）はそのブロックの最後の行か、(もし別のスタイルルールが許しているなら)開き中括弧（'}'）と同じ行に書くこと。
  • 閉じ括弧（')'）と開き中括弧（'{'）の間にはスペースを入れるべきではない。
  • パラメータにはすべて、宣言や実装と同じ名前を付けておくべきだ。
  • パラメータはすべて、できるだけ整列させるべきだ。
  • デフォルトのインデントはスペース2つにする。
  • ラップしたパラメータはスペース4つでインデントする。

もし関数が const であれば、const キーワードは最後のパラメータと同じ行に書くべきだ:

// この関数シグニチャはすべて1行に収まっている。 ReturnType FunctionName(Type par) const { ... } // この関数シグニチャには複数行必要になるが、 // const キーワードは最後のパラメータと同じ行に書いている。 ReturnType ReallyLongFunctionName(Type par1, Type par2) const { ... }

もし使われていないパラメータがあれば、関数の定義にある変数名をコメントアウトしておく:

// インタフェースにおけるパラメータには必ず名前を付ける。 class Shape { public: virtual void Rotate(double radians) = 0; } // 宣言におけるパラメータには必ず名前を付ける。 class Circle : public Shape { public: virtual void Rotate(double radians); } // 定義されているが使っていないパラメータの名前はコメントアウトしておく。 void Circle::Rotate(double /*radians*/) {} // よくない - 後で誰かが実装しようとしたとき、変数が何を意味しているかわからない。 void Circle::Rotate(double) {} 可能であれば1行に収める。収まらなければ、括弧で引数をくるむ。

関数呼び出しは次のような書式にする:

bool retval = DoSomething(argument1, argument2, argument3);

もし引数が1行に収まらなければ複数の行に分割して、以降の行は最初の引数で整列させるべきだ。開き括弧の後や閉じ括弧の前にスペースを入れてはいけない:

bool retval = DoSomething(averyveryveryverylongargument1, argument2, argument3);

関数に引数がたくさんあるときには、コードが読みやすくなるなら、1行につき引数を1つ書くことを検討する:

bool retval = DoSomething(argument1, argument2, argument3, argument4);

関数シグニチャが長すぎて最大の行の長さに収まらないときには、すべての引数を次の行以降に書いても構わない:

if (...) { ... ... if (...) { DoSomethingThatRequiresALongFunctionName( very_long_argument1, // スペース4つでインデント argument2, argument3, argument4); } 括弧の中にはスペースを入れない方が望ましい。else キーワードは新しい行にする。

基本的な条件文には2つの書式が許されている。1つは括弧と条件との間にスペースを入れるもので、もう1つは入れないものだ。

よく見かけるのはスペースが入っていない書式だ。どちらでもいいのだが、一貫性を持たせること。もし既存のファイルを変更しているのであれば、そこで使われている書式を使うこと。もし新しくコードを書いているのであれば、そのディレクトリやプロジェクトで使われている他のファイルの書式を使うこと。よくわからなくて個人的な好みがないのであれば、スペースを入れないでおこう。

if (condition) { // no spaces inside parentheses ... // スペース2つでインデント。 } else { // else は閉じ中括弧と同じ行に続ける。 ... }

好みで括弧の中にスペースを入れても構わない:

if ( condition ) { // 括弧の中にスペースを入れる - めったにない ... // スペース2つでインデント。 } else { // else は閉じ中括弧と同じ行に続ける。 ... }

if と開き括弧との間には必ずスペースを1つ入れなければならないことに注意すること。中括弧を使うときには閉じ括弧と中括弧との間にもスペースを1つ入れなければならない。

if(condition) // よくない - IF の後にスペースを入れていない。 if (condition){ // よくない - { の前にスペースを入れていない。 if(condition){ // 2重によくない。 if (condition) { // よい - IF の後も { の前にも正しくスペースを入れている。

もしその方が読みやすければ、短い条件文を1行に書いても構わない。この行が簡潔であって、文に else 節がないときにだけこれが許される。

if (x == kFoo) return new Foo(); if (x == kBar) return new Bar();

if文に else があるときには、これは許されない:

// 許されない - ELSE節があるときには、IF文を1行に書くこと if (x) DoThis(); else DoThat();

一般に、1行だけの文に中括弧を付ける必要はないが、中括弧を使うのが好みであればそうしても構わない。複雑な条件や文を含む条件文やループ文の場合、中括弧を使った方が読みやすいかもしれない。if には必ず中括弧を付けなければならない、としているプロジェクトもある。

if (condition) DoSomething(); // スペース2つでインデント。 if (condition) { DoSomething(); // スペース2つでインデント。 }

しかし、同じif-else文のなかで中括弧を使っているところがあれば、他のところでも中括弧を使わなければならない。

// 許されない - IF には中括弧があるが ELSE には中括弧がない if (condition) { foo; } else bar; // 許されない - ELSE には中括弧があるが IF には中括弧がない if (condition) foo; else { bar; } // IF/ELSE節の1つに中括弧が使われているため、 // IF と ELSE の両方に中括弧が必要になる。 if (condition) { foo; } else { bar; } スイッチ文のブロックには中括弧を使っても構わない。空ループの本体には、{} か continue を使うべきだ。

switch の case ブロックには中括弧を付けても付けなくてもよい。もし中括弧を付けるのであれば、以下のようにすべきだ。

もし条件が列挙値でなければ、switch文にはいつもdefault ケースを入れておくべきだ（列挙値の場合は、コンパイラが値が処理されないということを警告してくれる）。もしdefault ケースが実行されるべきでないときには、単に assert を書いておこう:

switch (var) { case 0: { // スペース2つでインデント ... // スペース4つでインデント break; } case 1: { ... break; } default: { assert(false); } }

空ループの本体には、{} や continue を使うべきだ。セミコロンだけにすべきではない。

while (condition) { // false が返ってくるまでテストを繰り返す。 } for (int i = 0; i < kSomeNumber; ++i) {} // よい - 空の本体。 while (condition) continue; // よい - continue はロジックがないことを示している。 while (condition); // よくない - do/while ループの一部のように見える。 ピリオドや矢印のまわりにはスペースを入れない。ポインタ演算子には後ろにスペースを付けない。

ポインタとリファレンス表現の正しい書式の例を挙げる:

x = *p; p = &x; x = r.y; x = r->y;

以下に注意すること:

  • メンバにアクセスするときにはピリオドや矢印のまわりにスペースを入れないこと。
  • ポインタ演算子には * や & の後ろにスペースを入れないこと。

ポインタ変数やポインタ引数を宣言するときには、アスタリスクを型の側に置いてもいいし変数名の側に置いてもよい:

// These are fine, space preceding. char *c; const string &str; // These are fine, space following. char* c; // but remember to do "char* c, *d, *e, ...;"! const string& str; char * c; // Bad - spaces on both sides of * const string & str; // Bad - spaces on both sides of &

ファイル内では一貫性を持たせるべきだ。既存のファイルを変更するときには、そのファイルのスタイルに従うこと。

標準の行の長さよりも長いブーリアン表現を書くときには、行の分割方法に一貫性を持たせる。

この例では、論理積オペレータを常に行末に置いている:

if (this_one_thing > this_other_thing && a_third_thing == a_fourth_thing && yet_another & last_one) { ... }

&& 論理積オペレータは両方とも行の末尾にあることに注意しよう。余分な括弧を入れても構わない。うまくやると非常に読みやすくなる。

return 式を括弧で囲んではいけない。

戻り値は括弧で囲むべきではない。

return x; // return(x); にしない 初期化に = を使うか () を使うかは、自由に選んでよい。

初期化に = を使うか () を使うかは、自由に選べばよい。以下はすべて正しい書き方になる:

int x = 3; int x(3); string name("Some Name"); string name = "Some Name"; プリプロセッサディレクティブはインデントすべきではない。行の先頭から開始するべきだ。

プリプロセッサディレクティブがインデントされたコードの本体の中にあるときでも、ディレクティブは行の先頭から始めるべきだ。

// よい - ディレクティブが行の先頭にある。 if (lopsided_score) { #if DISASTER_PENDING // 正しい -- 行の先頭から始まっている。 DropEverything(); #endif BackToNormal(); } // よくない - ディレクティブをインデントしている if (lopsided_score) { #if DISASTER_PENDING // 間違い! "#if" は行の先頭にあるべき。 DropEverything(); #endif // 間違い! "#endif" をインデントしてはいけない。 BackToNormal(); } public、protected、private の各セクションはこの順序で書く。スペース1つでインデントすること。

クラス定義の基本となる書式は次のようになる（ここにはコメントを入れていないが、どんなコメントが必要かについては、クラスのコメントを参照すること）:

class MyClass : public OtherClass { public: // スペース1つでインデントしていることに注意! MyClass(); // 通常のスペース2つでインデント。 explicit MyClass(int var); ~MyClass() {} void SomeFunction(); void SomeFunctionThatDoesNothing() { } void set_some_var(int var) { some_var_ = var; } int some_var() const { return some_var_; } private: bool SomeInternalFunction(); int some_var_; int some_other_var_; DISALLOW_COPY_AND_ASSIGN(MyClass); };

注意すべきこと:

  • ベースクラス名はサブクラス名と同じ行に書くべきだ。80カラムの制限を受ける。
  • public:、protected:、private: キーワードはスペース1つでインデントするべきだ。
  • 最初の例を除いて、こうしたキーワードの前には空行を入れておくべきだ。このルールは小さいクラスの場合にはオプションだ。
  • これらのキーワードの後に空行を入れてはいけない。
  • public セクションがまず最初にきて、その後に protected、それから最後に private セクションがくるようにするべきだ。
  • セクション内の宣言の順序に関するルールについては、宣言の順序を参照すること。
コンストラクタのイニシャライザリストはすべて1行に書くか、もしくは以降の行にスペース4つでインデントして書いてもよい。

イニシャライザリストには2つの書式が許されている。

// すべて1行に収まるとき: MyClass::MyClass(int var) : some_var_(var), some_other_var_(var + 1) {}

または

// 複数行が必要なときはスペース4つでインデントして、 // イニシャライザの最初の行にコロンを入れる MyClass::MyClass(int var) : some_var_(var), // スペース4つでインデント some_other_var_(var + 1) { // 一列に並べる ... DoSomething(); ... } 名前空間の内容はインデントしない。

名前空間には余分なインデントをしないこと。例えば次のようにすること:

namespace { void foo() { // 正しい。名前空間内では余分なインデントをしない。 ... } } // namespace

名前空間内はインデントしてはいけない:

namespace { // 間違い。すべきではないインデント。 void foo() { ... } } // namespace 水平方向の空白を使うかは場所によって異なる。行末には空白を入れてはいけない。 void f(bool b) { // 開き中括弧の前には必ずスペースを1つ入れるべきだ。 ... int i = 0; // セミコロンの前には通常、スペースを入れない。 int x[] = { 0 }; // 配列の初期化のための中括弧にスペースを入れるのはオプションだ。 int x[] = {0}; // もし入れるのであれば、両側に入れること! // 継承とイニシャライザリストのコロンのまわりにはスペースを1つ入れる。 class Foo : public Bar { public: // インライン関数の実装には、中括弧とその実装自体との間にはスペースを1つ入れる。 Foo(int b) : Bar(), baz_(b) {} // 空の中括弧のなかにはスペースを入れない。 void Reset() { baz_ = 0; } // 実装と中括弧のあいだにはスペースを1つ入れる。 ...

末尾に空白が入っていると、もともとあった末尾の空白を削除して、他の人が同じファイルを編集してマージしようとしたときに余計な作業が発生することがある。だから、末尾に空白を入れてはいけない。もしちょうど末尾に空白のある行を変更しているのなら空白を削除しよう。あるいは、別のクリーンナップ操作の中でそうしよう（できれば誰もそのファイルで作業をしていないときに）。

if (b) { // 条件とループのキーワードの後のスペース。 } else { // else のまわりにはスペースを入れる。 } while (test) {} // 括弧のなかには通常スペースを入れない。 switch (i) { for (int i = 0; i < 5; ++i) { switch ( i ) { // ループと条件では、括弧のなかにスペースを入れても構わないが、 if ( test ) { // こうするのはまれだ。一貫性を持たせること。 for ( int i = 0; i < 5; ++i ) { for ( ; i < 5 ; ++i) { // ループでは、セミコロンの後に必ずスペースを1つ入れる。 ... // セミコロンの前にもスペースを1つ入れても構わない。 switch (i) { case 1: // switch 文の case のコロンの前にはスペースを入れない。 ... case 2: break; // コロンの後にコードを書くなら、コロンの後にスペースを1つ入れる。 x = 0; // 代入オペレータのまわりには必ずスペースを入れる。 x = -5; // 単項オペレータとその引数のまわりにはスペースを入れない。 ++x; if (x && !y) ... v = w * x + y / z; // 2項オペレータのまわりには通常スペースを入れるが、 v = w*x + y/z; // 倍数のまわりのスペースは削除しても構わない。 v = w * (x + z); // 括弧のなかにはスペースを入れるべきではない。 vector<string> x; // 山括弧（< と >）のなか、< の前、もしくは、 y = static_cast<char*>(x); // キャストにおける > と ( の間にはスペースを入れない。 vector<char *> x; // 型とポインタの間にはスペースを入れても構わないが、 // 一貫性を持たせること。 set<list<string> > x; // C++ では > と > の間にスペースが1つ必要になる。 set< list<string> > x; // オプションで、< と < の間に対称となるようスペースを // 入れても構わない。 垂直方向の空白は最小限にする。

これはルールというよりも原則だ。必要のない空行を入れてはいけない。具体的に言うと、関数と関数の間に1、2行以上の空行を入れてはいけない。関数を空行で始めてはいけないし、空行で終わってはいけない。関数内で空行を使うときには厳選すること。

基本原則: コードが1画面にうまく収まれば収まるほど、プログラムの制御フローは追いやすく理解しやすくなる。言うまでもないことだが、コードが密集しすぎても広がりすぎても、読みやすくはならない。自分で判断しよう。しかし一般的には、垂直方向の空白の使用は最小限にすること。

関数を空行で始めてはいけないし、空行で終わってもいけない: void Function() { // 前後に不必要な空行がある }

ブロックを空行で始めてはいけないし、空行で終わってもいけない: while (condition) { // 後ろに不必要な空行がある } if (condition) { // 前に不必要な空行がある } ただし、if-else ブロックの間には空行を入れても構わない。 if (condition) { // 別の機能に移るにはあまりにコードが少ないので、 // 空行を入れておく。 } else { // 別のコードブロック }

ここに記載したコーディング規約は必須のものだ。しかし、どんな優れたルールにも、時には例外がある。ここで説明しよう。

このスタイルガイドに従っていないコードを扱うときには、ルールを逸脱しても構わない。

このガイドにあるルールではなく別の仕様に合わせて書かれたコードに手を入れることもあるだろう。その場合、ローカルなコード規約と一貫性を持たせるために、このガイドにあるルールから逸脱する必要があるかもしれない。これに疑問を感じるのであれば、そのコードの原作者や現在の責任者に尋ねよう。ローカルな一貫性も含めて、一貫性を持たせることを忘れないようにしよう。

Windowsプログラマは自分たちのコーディング規約を作ってきた。これは主に、Windowsのヘッダファイルやその他のMicrosoftのコードに由来している。私たちはコードが誰にでも理解しやすいようにしたい。そのために私たちは、C++ を書く人たちのために、どんなプラットフォームでも使える1つのガイドラインを作った。

これまで蔓延しているWindowsスタイルを使っていたのなら、ガイドラインを忘れているかもしれない。もう一度言っておく必要があるだろう。

  • ハンガリアン記法を使ってはいけない。（例えば、整数に iNum という名前を付けたり）。Googleの命名規約に従って、ソースファイルには .cc という拡張子を付けること。
  • Windowsはプリミティブ型に様々な別名を定義している。例えば、DWORD や HANDLE など。Windows API関数を呼び出すときには、こうした型を使っても全然構わないし、むしろ使うことを推奨する。ただしできるだけ、基本となるC++の型を使うようにすること。例えば、LPCTSTR ではなく const TCHAR * を使おう。
  • Microsoft Visual C++ でコンパイルするときには、警告レベルを3以上に設定して、すべての警告をエラーとして扱う。
  • #pragma once を使ってはいけない。代わりに標準的なGoogleのインクルードガードを使おう。インクルードガードに使うパスはプロジェクトツリーのトップに対する相対パスにするべきだ。
  • 実際のところ、絶対に必要なとき以外は、#pragma や __declspec といった非標準の拡張を使ってはいけない。__declspec(dllimport) や __declspec(dllexport) は使っても構わない。しかし、DLLIMPORT や DLLEXPORT といったマクロを通して使おう。こうしておくと簡単に無効にすることができる。

しかし、Windowsの場合には、時々破らざるを得ないルールがいくつかある。

  • 私たちは通常、実装の多重継承を使うことを禁止している。しかし、COMやATL/WTLクラスを使うときにはこれが必要になる。COMやATL/WTLクラスおよびインタフェースを実装するためであれば、実装の多重継承を使っても構わない。
  • 自分で書くコードには例外を使うべきではないが、ATLやSTL、Visual C++に関連するものには、いろいろなところに例外が使われている。ATLを使うときには、例外を無効にするために _ATL_NO_EXCEPTIONS を定義しておくべきだ。STLでも例外を無効にできるかどうか調べるべきだが、もしできないのならコンパイラで例外を無効にすればよい。（これはSTLをコンパイルするためだけのものだということに注意しよう。例外を処理するコードを自分で書くべきではない。）
  • プリコンパイルヘッダを使うときは通常、ソースファイルの先頭でヘッダファイルをインクルードする。これは通常、StdAfx.h や precompile.h という名前になっている。コードを他のプロジェクトと共有しやすくするために、明示的にファイルをインクルードするのではなく（precompile.ccの中を除く）、/FIコンパイルオプションを使って自動的にファイルがインクルードされるようにしよう。
  • リソースヘッダは通常 resource.h という名前にして、マクロだけが含まれるようにする。このスタイルガイドに従う必要はない。

常識を働かせよう、そして、一貫性を持たせよう。

ちょうどコードを書いているところなら、数分かけてまわりのコードを調べて、スタイルを決めよう。もし if 節のまわりに空白があるなら、あなたもそうすべきだ。もしコメントがスターで囲まれた小さなボックス状になっているなら、あなたのコメントもそうしよう。

スタイルガイドラインがあるということは、コーディングに共通のボキャブラリがあるということだ。このおかげで全員が、どうやって話すかではなく、何を話すかに集中することができる。このガイドラインでは、全体的なスタイルに関するルールについて説明した。これでボキャブラリについてはわかっただろう。しかし、ローカルなスタイルも重要だ。あなたの書いたコードが、まわりにある既存のコードと全然違っているように見えると、コードを読む人は不連続さを感じてリズムが狂ってしまう。これは避けるようにしよう。

OK、コードの書き方についてはもう十分だ。コードを書く方がずっとおもしろい。さあ、楽しもう!

Revision 3.133

Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray
（日本語訳 Takashi Sasai）