Revision 3.146
Benjy Weinbergerやったね！ このように矢印ボタンをクリックすると詳細情報が表示される。 このドキュメントの先頭にある大きな矢印ボタンをクリックしてもいい。詳細情報が全部表示される。
C++は、Googleのオープンソースプロジェクトの多くで使われている主要な開発言語だ。 C++プログラマなら誰でも知っているように、C++には強力な機能がたくさんあるが、その力ゆえに複雑になってしまっている。C++で書かれたコードはバグを生みやすく、読みにくくメンテナンスしにくくなるおそれがある。
このガイドが目標にしているのは、C++コードを書くときに「すべきこと」「すべきでないこと」を詳しく説明することによって、C++にある複雑さをどうにかうまくやるということだ。ここに挙げたルールは、C++の機能を利用して生産性を上げつつ、コードベースを管理しやすくするためにある。
スタイルとは読みやすさにも関連するが、ここではC++コードに適用する規約のことを指している。ここで「スタイル」という用語を使うのは、やや語弊があるかもしれない。規約にはソースファイルの書式以上のものを含んでいるためだ。
コードベースを管理しやすくする方法の1つは、強制的に一貫性を持たせることだ。どんなプログラマでもコードを見ればすぐに理解できる、ということは極めて重要なことだ。 みんなが一貫性のあるスタイルを維持して規約に従っていると、各種シンボルが何を意味していて、どの不変式が真であるのかといったことが、簡単な「パターンマッチング」で推測できるようになる。よく使うイディオムやパターンを作っておくと、コードは非常に理解しやすくなる。スタイルを曲げるのに十分な理由がある場合もあるだろう。しかし、それでもなお一貫性を維持することを重視して、私たちはそのままにしておくことを選んだ。
このガイドが解決するもう1つの問題は、肥大化したC++の機能についてだ。 C++は数多くの先進的な機能を備えた、巨大な言語だ。このガイドラインでは、場合によっては、特定の機能を制限したり、禁止することまでしている。これはコードをシンプルにすることで、こうした機能によって引き起こされる間違いや問題を回避するためだ。このガイドではそのような機能を列挙して、なぜその使用を制限したのかについても説明している。
Googleによって開発されているオープンソースプロジェクトは、このスタイルガイドに従っている。
このガイドはC++のチュートリアルではないことに注意しよう。読者はC++をよく知っていることを想定している。
一般的に、すべての .ccファイルには、対応する.hファイルを用意するべきだ。ただし、ユニットテストやmain()関数1つだけの.ccファイルなど、小さなファイルはこの限りではない。
ヘッダファイルを正しく使うと、コードの読みやすさ、サイズ、パフォーマンスを大きく改善することができる。
以下のルールに従うと、ヘッダファイルを使うときの落とし穴を避けることができる。
#define ガードを入れておくべきだ。#define ガードのシンボル名は、
<PROJECT>_<PATH>_<FILE>_H_ という書式にするべきだ。
シンボル名が一意であることを保証するため、プロジェクトのソースツリーのフルパスに基づいたシンボル名にするべきだ。例えば、foo というプロジェクトの foo/src/bar/baz.h というファイルの場合、#define ガードは次のようになる。
#include を使ってはいけない。
ヘッダファイルをインクルードすると依存関係ができてしまい、そのヘッダファイルを変更するたびに再コンパイルが必要になる。あなたの書いたヘッダファイルが他のヘッダファイルをインクルードしているとしよう。そうしたヘッダファイルを変更すると、あなたのヘッダファイルをインクルードしているコードまで、すべて再コンパイルが必要になってしまう。そのため、インクルードするヘッダファイルは最小限にしておくことが望ましい。特にヘッダファイル中で他のヘッダファイルをインクルードするのは避けるようにしよう。
前方宣言を使うと、ヘッダファイル中でインクルードするヘッダファイルの数を大幅に減らすことができる。例えば、ヘッダファイルで File クラスを使っていても、File クラスの宣言にアクセスする必要がないのであれば、ヘッダファイルに class File; と前方宣言しておくだけで十分だ。#include "file/base/file.h" とする必要はない。
Foo クラスの定義にアクセスせずに、ヘッダファイルで何ができるのか？
Foo* 型や Foo& 型のデータメンバを宣言することができる。
Foo 型の引数や戻り値を持つ関数を宣言（定義ではない）することができる。
Foo 型のスタティックデータメンバを宣言することができる。スタティックデータメンバはクラス定義の外部に定義されるためだ。
これに対して、書いているクラスが Foo のサブクラスであったり、そのクラスに Foo 型のデータメンバがあるのなら、Foo のヘッダファイルをインクルードしなければならない。
オブジェクトではなくポインタ（scoped_ptr の方が望ましい）をメンバにした方がふさわしい場合もある。しかしながら、こうするとコードは読みにくくなり、パフォーマンス面でも不利になる。ヘッダファイルのインクルードを最小限にすることだけが目的であれば、こうした置き換えをするのはやめておこう。
言うまでもないことだが、通常、.cc ファイルには利用するクラスの定義が必要になるので、ヘッダファイルをインクルードする必要がある。
インライン化するかどうかについては、優れた経験則がある。10行を超える関数はインライン化しないというものだ。ただし、デストラクタには注意すること。見た目以上に長いことがよくある。暗黙のうちに、メンバクラスのデストラクタとベースクラスのデストラクタが呼び出されるためだ。
役に立つ経験則がもう1つある。ループやスイッチ文のある関数をインライン化するのは、割に合わない。（ただし、よく見かける実行されることのないループやスイッチ文は除く）。
たとえ関数をインライン化するよう宣言してあっても、実際にインライン化されるとは限らないということを知っておくのは重要だ。例えば、仮想関数や再帰関数は通常、インライン化しない。また、再帰関数は通常、インライン化するべきではない。仮想関数をインライン化する主な理由は、仮想関数をクラスの定義に置くためだ。こうすると便利だったり、あるいは、アクセサやミューテータなどの動作を明記できるためだ。
-inl.hというサフィックスを持つファイルに書いても構わない。
インライン関数の定義はヘッダファイルに入れておく必要がある。これによって、コンパイラはその定義を呼び出し場所に埋め込むことができる。しかし、実装コードはきちんと .cc ファイルに置いておくべきだ。読みやすさやパフォーマンスにメリットがない限り、コードを.h ファイルにたくさん置くことは望ましくない。
インライン関数の定義が短くて、ロジックがほとんどないか、あっても少しであれば、.h ファイルにコードを入れておくべきだ。例えば、アクセサやミューテータは必ずクラス定義の内部に入れておくべきだ。もっと複雑なインライン関数であっても、実装者や利用者にとって便利であれば、.h ファイルに置いておいても構わない。しかし、.h ファイルが大きくなりすぎて扱いにくいなら、-inl.h という別のファイルにコードを入れてもいい。
クラス定義から実装が分離されてしまうことになるが、実装はきちんと必要な場所にインクルードされる。
-inl.h ファイルのもう1つの使い道は、関数テンプレートを定義する場所としてだ。テンプレートの定義を読みやすくするために、このファイルを使ってもよい。
-inl.h ファイルには #define ガードが必要だということを忘れないこと。これについては他のヘッダファイルと全く同じだ。
C/C++ 関数におけるパラメータは、関数への入力か、関数からの出力か、その両方であるかのいずれかになる。通常、入力パラメータは、値か const リファレンスのどちらかになる。これに対して、出力および入出力パラメータは、非 const ポインタになるだろう。関数パラメータを並べるときには、入力のみのパラメータをすべて置いてから、出力パラメータを置くようにすること。新しいパラメータだからといって、関数の最後に追加してはいけない。入力のみのパラメータを新しく追加するときには、出力パラメータの前に置くようにすること。
これは厳格なルールというわけではない。入力であり出力でもあるパラメータ（クラスや構造体であることが多い）が存在するので、このルールはきれいにはいかないためだ。また、例によって、関連する関数に一貫性を持たせるためには、ルールを曲げる必要があるかもしれない。
.h、プロジェクトの.h
プロジェクトのヘッダファイルはすべて、プロジェクトのソースディレクトリ配下にあるものとして書くべきだ。UNIXディレクトリのショートカットである .（カレントディレクトリ）や ..（親ディレクトリ）を使ってはいけない。例えば、
google-awesome-project/src/base/logging.h
をインクルードするときには、以下のようにする。
dir/foo.cc の主たる目的が、
dir2/foo2.h にあるものを実装することであったり、テストすることであれば、dir/foo.cc ではヘッダを次の順序でインクルードする。
dir2/foo2.h （望ましいところ
— 詳しくは下を参照）。.h ファイル.h ファイル
ここで推奨している順序にしておくと、依存関係が隠れにくくなる。私たちはすべてのヘッダファイルが、それ自身でコンパイルできるようにしたい。これを実現するいちばん簡単な方法は、すべてのヘッダファイルを、必ず .cc でインクルードされる最初の .h にしておくことだ。
dir/foo.cc と dir2/foo2.h は同じディレクトリに置いておくことが多い。（例えば base/basictypes_unittest.cc と base/basictypes.h）。しかし別のディレクトリに置いても構わない。
セクション内では、アルファベット順にインクルードしておくとよい。
例えば、google-awesome-project/src/foo/internal/fooserver.cc のインクルードは次のようになる。
.cc ファイルには、無名の名前空間を使うことを推奨する。名前付き名前空間を使うときには、プロジェクト名とできればパス名に基づいた名前にする。
名前空間はクラスによる（階層的な）名前の軸に加えて、（これもまた階層的な）名前の軸を提供する。
例えば異なる2つのプロジェクトがあり、どちらのプロジェクトにもグローバルスコープに Foo というクラスがある場合、コンパイル時もしくは実行時にシンボルが衝突するおそれがある。各プロジェクトの名前空間にコードを置いていれば、project1::Foo と project2::Foo という異なるシンボルになるため、衝突は起こらない。
名前空間を使うと、混乱してしまうおそれがある。クラスによる名前の（階層的な）軸に加えて、さらなる名前の（階層的な）軸を提供するためだ。
ヘッダファイルに無名のスコープを使うと、C++の単一定義規則（ODR、One Definition Rule）に違反してしまいやすくなる。
名前空間を使うときには、以下に説明するポリシーに従うこと。
.cc ファイルには無名の名前空間を使ってもよい。むしろ使うことを推奨する。
しかし、特定のクラスに関連するファイルスコープ宣言は、無名の名前空間のメンバとしてではなく、型やスタティックデータメンバ、スタティックメンバ関数としてそのクラスに宣言してもよい。この例にあるように、無名の名前空間を終了するときには // namespace というコメントを入れておくこと。
.h ファイルには無名の名前空間を使ってはいけない。
名前付き名前空間は次のようにすべきだ。
.cc ファイルは通常もっと複雑で、他の名前空間にあるクラスも参照する必要があるだろう。
std には何も宣言してはいけない。たとえ標準ライブラリに含まれるクラスの前方宣言であってもだ。名前空間 std に宣言したときの動作は定義されていない。つまり移植性がないということだ。標準ライブラリに含まれている要素を宣言するには、適切なヘッダファイルをインクルードすること。
.cc ファイルならどこでも、.h ファイルなら関数かメソッドかクラス内であれば、.cc ファイルならどこでも、.h ファイルなら関数かメソッド内であれば、名前空間のエイリアスを使ってもよい。
.cc ファイルで定義してもよい。こうするとネストされたクラスの定義を入れなくて済む。ネストされたクラスの定義は通常、実装だけに関連しているためだ。
Foo::Bar* ポインタを操作するヘッダファイルにはみな、Foo のクラス宣言をすべて入れておく必要があるだろう。
クラスのインスタンスに関連付けられていない関数を定義するのは役に立つこともあるし、時として必要になることもある。こうした関数はスタティックメンバ関数または非メンバ関数のいずれかにして構わない。 非メンバ関数は外部変数に依存するべきではなく、ほとんどの場合、名前空間内に存在するようにすべきだ。スタティックデータを共有していないスタティックメンバ関数をまとめたいときには、そのためだけにクラスを作るのではなく、代わりに名前空間を使うべきだ。
クラスと同じコンパイル単位に定義されている関数を別のコンパイル単位から直接呼び出すと、コンパイル時やリンク時に不必要な依存関係ができるおそれがある。スタティックメンバ関数の場合、特にこうなることが多い。新しいクラスを抽出したり、できれば別のライブラリの名前空間に関数を置くことを検討すること。
もし、非メンバ関数を定義する必要があって、それが .cc ファイル内でのみ必要であれば、無名の名前空間か static リンク （例えば static int Foo() {...}）を使ってスコープを制限すること。
C++では関数内のどこでも変数を宣言することができる。私たちはできるだけスコープを局所的にして、できるだけ初めて使う場所の近くで宣言することを推奨する。こうしておくとコードを読む人にとって、その変数の型が何であり、それがどう初期化されているのかが見つけやすくなる。具体的には、宣言や代入などを使う代わりに初期化を使うべきだ。
gcc は for (int i = 0; i < 10; ++i) を正しく実装していることに注意しよう。(i のスコープは for ループ内だけになる)。そのため、同じスコープにある別の for ループで、i をもう一度利用することができる。また、if や while 文における宣言のスコープも正しく実装されている。
1つ注意しておくべきことがある。変数がオブジェクトの場合、そのスコープに入るたびにコンストラクタが実行されてオブジェクトが生成される。そしてスコープから抜けるたびにデストラクタが実行されることになる。
したがって、ループ内で使う変数は、ループの外側で宣言しておく方が効率がよいかもしれない。
グローバル変数やスタティック変数、スタティッククラスメンバ変数、関数スタティック変数を含む静的記憶域期間のあるオブジェクトは、POD（Plain Old Data）でなければならない。PODとは、int、char、float、ポインタ、および、PODの配列/構造体だけだ。
C++では、コンストラクタとスタティック変数のイニシャライザが呼ばれる順序が部分的にしか決まっておらず、ビルドするたびに変わる可能性がある。これは発見困難なバグを引き起こすおそれがある。そのため、クラス型のグローバル変数を禁止することに加えて、関数の結果でスタティックなPOD変数を初期化してはいけない。ただし、(getenv()やgetpid()のように)関数が他のグローバル変数に依存している場合は除く。
さらに、デストラクタが呼ばれる順序はコンストラクタが呼ばれる順序の逆順だと定義されている。コンストラクタの呼び出し順序が不定なので、デストラクタの呼び出し順序も不定になる。例えば、プログラム終了時にスタティック変数は破壊されるかもしれないが、まだ動いているコードが（おそらく別のスレッドで）その変数にアクセスしようとして失敗するかもしれない。あるいは、スタティックなstring変数のデストラクタが、その文字列への参照を含む別の変数のデストラクタより前に、呼び出されてしまうかもしれない。
結局のところ、スタティック変数はPODデータを含むときにだけ使ってもよいということだ。このルールは vector（代わりに、Cの配列を使おう）や string（代わりに、const char* を使おう）も許していない。
もしクラス型のスタティック変数やグローバル変数が必要であれば、main() 関数か pthread_once() 関数から（決して free されることのない）ポインタを初期化することを検討しよう。これはスマートポインタではなく、ただのポインタでなければならないことに注意しよう。スマートポインタのデストラクタには、回避しようとしてきたデストラクタの順序問題があるためだ。
static クラスメンバ変数はグローバル変数とみなされることに注意すること。したがってクラス型にしてはいけない。
Init() メソッドに入れるべきだ。
main() 関数よりも前に呼び出されてしまう。おそらくこれは、コンストラクタのコードにとって想定外のことだろう。
例えば gflags はまだ初期化されていない。
Init() メソッドを用意することを検討すること。特にコンストラクタでは、仮想関数を呼び出したり、エラーを発生しようとしたり、初期化されていない可能性のあるグローバル変数にアクセスしたりするべきではない。
new すると、デフォルトコンストラクタが呼び出される。 new[] したときにもデフォルトコンストラクタが呼び出される（配列の場合）。
もしクラスにメンバ変数を定義していて他にコンストラクタがないのであれば、デフォルトコンストラクタ（引数をとらないコンストラクタ）を定義しなければならない。こうしたオブジェクトは、できるだけ矛盾のない有効な内部状態になるよう、初期化しておくべきだ。
これは、他にコンストラクタがないのにデフォルトコンストラクタを定義していないと、コンパイラがコンストラクタを生成してしまうためだ。コンパイラが生成したコンストラクタは、オブジェクトをうまく初期化してくれないかもしれない。
もしそのクラスが既存のクラスから継承したものであり、新しいメンバ変数を追加していないのであれば、デフォルトコンストラクタを持つ必要はない。
explicit キーワードを付けること。
Foo::Foo(string name) が定義してあるとしよう。Foo を期待している関数に文字列を渡すと、コンストラクタが呼び出されて文字列を Foo に変換する。そして、関数にはその Foo が渡されることになる。これは便利だ。しかし、変換によって暗黙のうちに新しいオブジェクトが生成されるのは、トラブルの原因にもなる。コンストラクタに explicit を宣言しておくと、暗黙に変換されてしまうのを防ぐことができる。
私たちは1つの引数をとるコンストラクタにはすべて、explicit を付けることにする。クラス定義において、引数が1つのコンストラクタの前には必ず explicit を付けること。
explicit Foo(string name);
ただし、コピーコンストラクタについては例外だ。こういうケースはめったにないのだが、explicit を付けるべきではないだろう。
他のクラスに対する透過的なラッパーとして使うクラスもまた例外だ。
こういう例外については、コメントにはっきりと明記しておくべきだ。
DISALLOW_COPY_AND_ASSIGN によって、これらを無効にしておくこと。
CopyFrom()スタイルの回避策よりも効率がよい。なぜなら、これはコピーの解釈を兼ねており、コンテキストによってはコンパイラがコピーを省略して、ヒープ割り当てを簡単に回避できるためだ。
ほとんどのクラスはコピー可能である必要はなく、コピーコンストラクタも代入オペレータも持つべきではない。たいていの場合、ポインタやリファレンスを使えば、コピーされた値と同じ振る舞いを、よりよいパフォーマンスで実現できるだろう。例えば、関数パラメータを値ではなくリファレンスやポインタで渡すことができるし、STLコンテナにオブジェクトではなくポインタを格納することができる。
もしクラスがコピー可能である必要があれば、コピーコンストラクタよりも CopyFrom() や Clone() といったコピーメソッドを提供する方が望ましい。なぜなら、こうしたコピーメソッドは暗黙に呼び出されることはないためだ。もしコピーメソッドでは不十分な状況の場合（例えば、パフォーマンス理由や、クラスがSTLコンテナの値として格納する必要があるため）には、コピーコンストラクタと代入オペレータの両方を提供すること。
もしクラスにコピーコンストラクタや代入オペレータが必要なければ、明示的に無効にしなければならない。
そのために、クラスの private: セクションに、コピーコンストラクタと代入オペレータのダミー宣言を追加すること。ただし対応する定義を提供してはいけない（そうしておけば、使おうとするとリンクエラーになる）。
便利な DISALLOW_COPY_AND_ASSIGN マクロを使うことができる。
そして class Foo の中では次のようにする。
struct はデータを運ぶ受動的なオブジェクトだけに使うこと。それ以外はすべて class を使うこと。
C++では、struct と class というキーワードはほとんど同じ動作になる。そこで私たちはキーワードに意味を持たせることにした。定義するデータの種類に合わせて、キーワードを使い分けるべきだ。
struct はデータを運ぶ受動的なオブジェクトに使うべきだ。定数と関連付けてもよいが、データメンバの取得/設定以外の機能を持たせてはいけない。フィールドの取得/設定は、メソッド呼び出しではなくフィールドに直接アクセスすることにより実行する。メソッドは動作を提供するべきではなく、データメンバの設定にのみ使われるべきだ。つまりコンストラクタ、デストラクタ、Initialize()、Reset()、Validate() などだけにすること。
もっと機能が必要であれば class を使う方が適している。はっきりしなければ class にしておこう。
STLと一貫性を持たせるために、functor や traint には class ではなく struct を使っても構わない。
構造体とクラスのメンバ変数には異なる命名規則があることに注意すること。
public 継承にすること。
継承はすべて public にするべきだ。もしプライベート継承を使いたければ、代わりにベースクラスのインスタンスをメンバとして持たせるべきだ。
実装の継承を使いすぎてはいけない。実際のところコンポジションの方がふさわしい場合が多い。継承は "is-a" の関係があるときだけ使うようにしてみよう。
もし Bar は Foo の一種（a kind of）だと無理なく言えるのであれば、Bar は Foo のサブクラスにしてもよい。
protected を使うのは、サブクラスからアクセスされる必要があるかもしれないメンバ関数だけに制限しよう。データメンバはプライベートにすべきだということに注意しよう。
継承した仮想関数を再定義するときには、派生したクラスの宣言で virtual だと明示的に宣言すること。virtual を省略してしまうと、コードを読む人はその関数が仮想関数かどうかを確認するために、そのクラスのすべての先祖をチェックしなければいけなくなるためだ。
Interface というサフィックスのついた純粋なインタフェースクラスであるときのみ、多重継承を使っても構わない。
Interface というサフィックスで終わらなければならない。
Interface というサフィックスを付けてもよい。ただし、これは必須ではない。
クラスが次の条件に当てはまるのであれば、それは純粋なインタフェースだ。
= 0"）メソッドとスタティックメソッドしかない（ただし、デストラクタについては以下を参照）。
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() のような関数を定義すればよい。同様に、そのクラスが前方宣言される可能性があるなら、いかなる犠牲を払っても、単項 operator& を避けるようにしよう。
しかし、オペレータのオーバーロードが必要になるケースもまれにある。それはテンプレートや "標準" C++クラス（ログのための operator<<(ostream&, const T&) など）と一緒に使うときだ。十分妥当な理由がある場合にはオペレータのオーバーロードを使ってもよいが、できるだけ避けるべきだ。具体的には、STLコンテナのキーとして使えるからといって operator== や operator< をオーバーロードしてはいけない。代わりに、コンテナを宣言するときには等価と比較の functor 型を作るべきだ。
STLアルゴリズムには operator== のオーバーロードが必要なものもある。その場合にはオーバーロードをしてもよいが、その理由を明記しておくこと。
コピーコンストラクタと関数のオーバーロードも参照すること。
private にして、必要に応じてアクセサ関数でアクセスできるようにすること（技術的理由のため、Google Test を使うときには、test fixtureクラスのデータメンバを protected にしてもよい）。通常は、変数を foo_ に、アクセサ関数を foo() という形式にする。ミューテータ関数は set_foo() という形式にしてもよい。
アクセサの定義は通常、ヘッダファイルにインライン化しておく。
public: は private: の前に置く、メソッドはデータメンバ（変数）の前に置くなど。
クラスの定義は public: セクションから始めて、protected: セクション、private: セクションという順にするべきだ。セクションが空であれば省略する。
各セクション内では通常、次の順序で宣言するべきだ。
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 を付けなければならない。
int foo(int *pval) など。C++では別の方法として、リファレンスパラメータを宣言することができる。int foo(int &val)
(*pval)++ といった見苦しいコードを避けることができる。コピーコンストラクタのような応用にも、リファレンスは必要になる。ポインタとは異なり、リファンレンスを使うと NULL が取り得る値でないことを明確にすることができる。
関数パラメータのリストでは、すべてのリファレンスに const を付けなければならない。
実際のところ、入力引数は値、もしくは const リファレンスであり、出力引数はポインタであるというのが、Googleコードにおける非常に厳格な規約だ。入力パラメータに const ポインタを使っても構わないが、非const のリファレンスを使うことは許されない。
入力パラメータを const ポインタにしたくなるケースもある。例えば、引数をコピーしておらず、オブジェクトの生存期間中はその引数が存在する必要があることを強調したいような場合だ。これは通常、コメントに明記しておくのがいちばんだろう。bind2nd と mem_fun のようなSTLアダプタは、リファレンスパラメータを許していない。このような場合には、ポインタをパラメータとする関数も宣言しなければならない。
const string& を引数とする関数を書き、それをconst char*を引数とする別の関数でオーバーロードしても構わない。
Append() ではなく、AppendString() や AppendInt() とする。
alloca() を使ってはいけない。
alloca() はどちらも非常に効率がよい。
scoped_ptr/scoped_array といった安全なアロケータを使うこと。
friend クラスや friend 関数を使ってもよい。
フレンドは通常、同じファイルに定義しておくべきだ。そうすれば、コードを読む人は他のファイルの中身を見ることなく、クラスのプライベートメンバが使われている場所を見つけることができる。friend がよく使われるのは、FooBuilder クラスを Foo のフレンドにするというものだ。これによって、Foo の内部状態を全員に公開することなく、FooBuilder クラスは正しくオブジェクトを構築することができる。ユニットテストのクラスを、テスト対象となるクラスのフレンドにしておくと便利な場合もある。
フレンドはクラスのカプセル化の範囲を拡大するものだが、カプセル化を破るものではない。他のクラス1つだけからアクセスできるようにしたい場合には、メンバをパブリックにするよりも都合がよいときもある。しかし、たいていの場合、クラスはパブリックメンバを介して別のクラスとやり取りするべきだ。
Init() メソッドによってシミュレーションすることはできるが、それにはヒープ割り当てや、新しい「不正な」状態というものが必要になる。throw 文を追加するときには、途中にある呼び出し元をすべて調査しなければならない。少なくとも、基本的な例外の安全性を保証するか、例外を捕捉せずに結果としてプログラムが中断してしまうことを良しとしなければならない。例えば、f() が g() を呼び出し、g() が h() を呼び出していて、h が f により捕捉される例外を投げているときには、g は気をつける必要がある。さもなければ、適切にクリーンナップされないおそれがある。表面的には、例外を使うメリットはコストを上回っている。特に、新規プロジェクトの場合にはそうだろう。しかし、既存のコードに例外を導入しようとすると、依存しているコードすべてに影響が及んでしまう。もし、例外が新しいオブジェクト以外にも影響を与えてしまうのであれば、その新規プロジェクトを例外のない既存コードに組み込むことは問題になる。Googleの既存のC++コードの多くは、例外を処理するようにできていないので、例外を生成するような新しいコードを採用するのは、どちらかと言うと難しい。
Googleの既存コードには例外に対する耐性がないことを考慮すると、Googleのプロジェクトで例外を使うのは、新規プロジェクトで例外を使うのと比べて、コストが多少大きいと言えるだろう。例外の変換プロセスには時間がかかり、問題になることが多い。そして、私たちはエラーコードやアサーションといった例外の代わりに使える方法が、大きな障害になるとは考えていない。
例外を使うことへの反対意見には、賢明な、あるいは高潔な理由があるわけではない。これは現実的な理由からだ。 Googleではオープンソースプロジェクトを使いたいのだが、こうした理由から例外を使っているプロジェクトを採用するのは難しい。したがって、Googleのオープンソースプロジェクトでも、例外に対して反対意見を述べざるを得ない。 スクラッチからもう一度全部やり直せるのであれば、おそらく考えは違っていただろう。
Windowsのコードに関しては、このルールは例外だ（シャレじゃないよ）。
ユニットテストの場合に、これは便利だ。例えば、ファクトリクラスのテストにおいて、新しく生成されたオブジェクトが期待通りの動的な型であることを確認するのに使えるだろう。
まれではあるが、テスト以外でも役に立つことがある。
ユニットテスト以外では RTTI を使ってはいけない。オブジェクトのクラスによって異なる動作をするようなコードを書く必要があれば、別の方法で型を問い合わせることを検討しよう。
サブクラスの型によって異なるパスでコードを実行したいときには、仮想メソッドを使うのがふさわしい。それぞれの処理は各オブジェクトの内部に置けばよい。
現在処理中のコードではなく、オブジェクトの外部に処理があるときには、Visitorデザインパターンのようなダブルディスパッチを使うことを検討しよう。ダブルディスパッチを使えば、オブジェクトの外部にあるものが組み込みの型システムを使ってクラスの型を決定することができる。
こうしたアイデアをどうしても使えないと思うのなら、RTTIを使っても構わない。しかし、そうする前にもう一度考えよう。:-) それから、もう一度考えよう。 RTTIに似たような回避策を自前で実装してはいけない。RTTIに対する議論は、型タグを持つクラス階層といった回避策にもほとんどそのまま当てはまるためだ。
static_cast<>() といった、C++のキャストを使うこと。int y = (int)x; や int y = int(x); といった書式のキャストを使ってはいけない。
(int)3.5）、キャストが行われることもある（例えば、(int)"hello"）。C++のキャストを使うと、こうした不明確さを避けることができる。さらに、C++のキャストの方が、使われているところを探すときに見てわかりやすい。
Cスタイルのキャストを使ってはいけない。代わりに、C++スタイルのキャストを使うこと。
static_cast を使うこと。
const 修飾子（constを参照）を取り除くためには、const_cast を使うこと。
reinterpret_cast を使うこと。ただし、何をやっているのか理解していて、エイリアスの問題を理解しているときだけ使うこと。
dynamic_cast を使ってはいけない。
ユニットテスト以外で実行時に型情報を知る必要があるなら、おそらく設計上の欠陥がある。
printf() や scanf() の代わりだ。
printf でも問題は起こらない）。ストリームには自動のコンストラクタとデストラクタがあり、対応するファイルのオープンとクローズを自動的にやってくれる。
pread() のような動作を実現するのは難しい。 printf のようなハックを使わずにストリームを使って効率よくやるのは、不可能ではないが複雑な書式になることがある（具体的には、よく見かける文字列イディオム %.*s）。ストリームは国際化に役立つオペレータの並び換え（%1s ディレクティブ）をサポートしていない。
ログ記録のためのインタフェースとして必要となる場合を除いて、ストリームは使わないこと。代わりに printf といったルーチンを使うこと。
ストリームの使用については、賛否両論ある。しかし、この場合も例によって、一貫性を持つことが最優先となる。コードにストリームを使ってはいけない。
この問題には長い議論があったので、理由についてもっと詳しく説明しておこう。方法を1つにすることが原則を導くということを思い出そう。特定のI/Oの型を使うときにはいつでも、コードのどこであっても同じように見えるようにしたい。そのため、ストリームと read/writeなどや printf のどちらを使うのか、ユーザが決められるようにはしたくない。そうではなく、どちらか一つに決めておくべきだ。ただし、ログ記録については例外とした。これはかなり特殊なアプリケーションであり、歴史的な理由もあるためだ。
ストリームの提案者たちは、ストリームの方が選ばれるのは疑う余地がないと主張していたが、実際のところ問題はそれほど明快なものではない。彼らが挙げるストリームの利点に対して、同じだけの欠点を挙げることができる。ストリームの最大の利点は、プリントするのにオブジェクトの型を知る必要がないことだ。これは疑う余地がないだろう。しかし、ここにはマイナス面もある。間違った型を使ってしまいやすく、たとえ間違っていてもコンパイラは警告してくれない。ストリームを使うと、知らず知らずのうちに次のような間違いをしやすくなる。
この場合、コンパイラはエラーを吐いてはくれない。<< がオーバーロードされているためだ。これが理由で、私たちはオーバーロードを使うことを推奨していない。
printf は不細工で読みにくいという人もいるが、ストリームにも同じことが言えるだろう。次の2つのコードを見てみよう。どちらにも同じ typo がある。どちらの方が見つけやすいだろうか？
他にもいろいろと問題を挙げることができる。（あなたは「ラッパーを使えば改善できる」と主張するかもしれない。しかしあるスキーマでそれが正しければ、他のスキーマでも正しいわけではないよね？ それに、私たちの目標は、言語をもっと小さくすることであって、学習しなければならない仕組みをさらに追加することではない。）
どちらをとっても異なる利点と欠点があり、明らかに優れた解決策というものはない。しかし、シンプルさの原則に従って、どちらか1つに決めなければならなかった。そして結局、多数決で printf + read/write になったのだ。
++i）で使うこと。
++i や i++）、デクリメントしたり（--i や i--）して、その式の値を使わないとき、前置インクリメント（デクリメント）か後置インクリメント（デクリメント）のどちらを使うか選ばなければならない。
++i）は「後置」形式（i++）よりも効率が悪くなることはなく、効率がよくなることが多い。後置インクリメント（またはデクリメント）の場合、i のコピー（これが式の値になる）を作る必要があるためだ。もしiがイテレータであったり、非スカラ型であれば、i をコピーするコストは高くなるだろう。
値が無視されるときにはこの2種類のインクリメントは同じような動作になるのに、どうして前置インクリメントだけにしないのか?
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 を最初に置くことを推奨するのだが、必須にはしていない。しかし、まわりのコードと一貫性を持たせること。
int だけだ。プログラムに別のサイズの変数が必要であれば、 <stdint.h> にある int16_t といった固定幅の型を使うこと。
shortは16ビット、intは32ビット、longは32ビット、long longは64ビットになる。
<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では、実際に引き起こされるバグが文書化のメリットを上回ってしまう。考えてみよう。
このコードは止まらない! gccはこのバグに気づいて警告してくれるが、気づかないことも多い。同じように、signed と unsigned を比較するときにも、ひどいバグが引き起こされる場合がある。要するに、Cの型昇格の仕組みによって、unsigned 型は期待とは異なる動作になってしまうのだ。
そのため変数が負ではないことを示すにはアサーションを使うこと。unsigned 型を使ってはいけない。
printf() の指定子には、32ビットシステムと64ビットシステムとの間で移植性があるかはっきりしていないものがある。C99は移植性のある書式指定子をいくつか定義している。残念ながらMSVC 7.1はこうした指定子のいくつかを理解できず、標準は少し欠けている。そのため場合によっては、自分で不細工なバージョンを定義する必要がある（標準のインクルードファイル inttypes.h のスタイルで）。
| 型 | 使ってはいけない | 使ってもいい | 注意 |
|---|---|---|---|
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()) を使うことができる。
LL や ULL というサフィックスを使うこと。例えば次のようになる。
#ifdef _LP64 を使うこと。（ただし、できればこれを避けて、変更が局所的になるようにすること）
const 変数を使う方が望ましい。
マクロを使うということは、あなたが見ているコードとコンパイラが見ているコードは同じではなくなるということだ。これは予期せぬ動作を引き起こすことがある。特に、マクロがグローバルスコープにあるときには起こりやすい。
幸運にも、C++ではCほどマクロは必要にならない。パフォーマンスに影響を及ぼすコードをインライン化するためには、マクロではなくインライン関数を使うこと。定数を格納するためには、マクロではなく const 変数を使うこと。長い変数名を省略するためには、マクロではなくリファレンスを使うこと。コードを条件付きコンパイルするためには、マクロではなく、いや、そもそもそんなことをしてはいけない（もちろん、ヘッダファイルの二重インクルードを防ぐための #define ガードは除く）。そんなことをするとテストがとても難しくなる。
こうした他のやり方ではできない場合には、マクロを使っても構わない。コードベース、特に低レベルのライブラリの中では見かけることがある。また、特別な機能には、言語によってはうまく利用できないものもある（文字列化、連結など）。しかしマクロを使う前には、マクロを使わないで同じ結果を達成する方法がないか注意深く検討すること。
次に示す利用パターンに従うと、マクロを使ったときの問題の多くを避けることができるだろう。マクロを使うときにはできるだけ以下に従うこと。
.h ファイルにマクロを定義してはいけない。
#define マクロを置き、使った直後に #undef すること。
#undef してはいけない。代わりに一意な名前を持つマクロにすること。
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(型) の方が理にかなっている場合もあるが、一般的には避けるべきだ。変数の型を変更すると一致しなくなるおそれがある。
boost/compressed_pair.hpp）
boost/ptr_container）ただしシリアライゼーションを除く。
boost/array.hpp）
boost/graph）ただしシリアライゼーションを除く。
boost/property_map.hpp）
boost/iterator/iterator_adaptor.hpp、
boost/iterator/iterator_facade.hpp、
boost/function_output_iterator.hpp一貫性を保つ上で最も重要なルールは命名に関するものだ。命名スタイルがあると、名付けられたものが何であるのか、型や変数、関数、定数、マクロといったことがすぐにわかるようになる。宣言を探す必要はなくなる。頭の中のパターンマッチングエンジンは命名規則をとても頼りにしている。
命名規則というものはかなりいい加減なものだが、個人の好みよりも一貫性を持つことの方が重要だと考えている。だから、理にかなっていると感じようが感じまいが、ルールはルールだ。
無理のない範囲で、できるだけわかりやすい名前にすること。スペースを節約しようとしてはいけない。新しくコードを読む人がすぐに理解できるようすることの方が、はるかに重要だ。よい名前の例を以下に挙げる。
よくない名前とは、曖昧な省略や意味のないいい加減な言葉を使うことだ。
型と変数の名前は通常、名詞にするべきだ。例えば、FileOpener、num_errors。
関数名は通常、命令的なものにするべきだ（つまりコマンドにするべきだ）。例えば OpenFile()、set_num_errors()。アクセサは例外であって、アクセスする変数と同じ名前にしておくこと。関数名で詳しく説明している。
プロジェクト外で極めてよく知られた言葉でない限り、略語を使ってはいけない。例:
文字を削って短縮してはいけない。
_）やダッシュ（-）を含んでいてもよい。プロジェクトで採用している規約に従うこと。もし、従うべき一貫性のあるパターンがないのであれば、"_" を使うのが望ましい。
許されるファイル名の例。
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つのファイルから構成されることになる。
-inl.h ファイルのセクションも参照すること。
MyExcitingClass、MyExcitingEnumなどとする。
あらゆる型、— クラス、構造体、typedef、enum — の名前には同じ命名規約を使う。型名は大文字で始めて、単語の先頭を大文字にするべきだ。アンダースコアは使わない。例:
my_exciting_local_variable、my_exciting_member_variable_。
例:
データメンバ（インスタンス変数やメンバ変数とも呼ばれる）は通常の変数名と同様に、アンダースコアを含む小文字にする。ただし、必ずアンダースコアで終わること。
構造体のデータメンバは、クラスのデータメンバにおける末尾のアンダースコアを除いて、通常の変数と同様に命名すべきだ。
構造体とクラスの使い分けについては、構造体 対 クラスを参照しよう。
グローバル変数については特別な決まりはない。グローバル変数はめったに使うべきではないが、もし使うのであれば g_ などのプレフィックスを付けてローカル変数と区別しやすくすることを検討しよう。
kで始まり、大文字小文字で続けること。例えば、kDaysInAWeek。
コンパイル時定数は、それがローカルであろうとグローバルであろうと、クラスの一部としてであろうと、どう宣言されていても、他の変数とは全然違う命名規約に従うこと。k の後に単語の先頭を大文字にして続けること。
MyExcitingFunction(),
MyExcitingMethod(),
my_exciting_member_variable(),
set_my_exciting_member_variable()
関数名は大文字で始めて、単語の先頭を大文字にするべきだ。アンダースコアは使わない。
アクセサとミューテータ（get/set 関数）は取得および設定しようとする変数名と一致させるべきだ。以下は、num_entries_ というインスタンス変数を持つクラスの一部を示している。
非常に簡潔なインライン関数には小文字を使っても構わない。例えば、ループの中でその関数を読んでも値をキャッシュしないような非常に簡単なものであれば、小文字で命名してもよい。
google_awesome_project。
名前空間とその命名については、名前空間を参照しよう。
kEnumName もしくは ENUM_NAME とする。
できれば、個々の列挙子は 定数 のようにするべきだ。しかし、マクロ のようであっても構わない。列挙型名 UrlTableErrors（そして、AlternateUrlTableErrors）は型であり、これは大文字と小文字を組み合わせた名前にする。
2009年1月までは、enum値は マクロ のように命名するというスタイルだった。これはenum値とマクロの名前の衝突という問題を引き起こした。そのため、定数スタイルの命名の方がよいという変更をした。新しいコードはできるだけ定数スタイルの命名にするべきだ。しかし、古い命名が実際にコンパイル時の問題を引き起していないのであれば、古いコードを定数スタイルの命名に変更する理由はない。
MY_MACRO_THAT_SCARES_SMALL_CHILDREN
マクロの説明を参照しよう。一般的にマクロは使うべきではない。しかしどうしても必要であれば、enum値の名前のように、大文字とアンダースコアだけを使った名前にするべきだ。
bigopen() open() の形に従うuint typedef bigpos struct や class。 pos の形に従う。sparse_hash_map LONGLONG_MAX INT_MAX と同様。コメントを書くのは苦痛だが、コードを読みやすくしておくためには不可欠だ。以下のルールは、どこにどんなコメントを書くべきかを説明したものだ。 しかし忘れないでほしい。コメントはとても重要だが、最高のコードとは自己文書化されたコードだ。曖昧な名前を付けてコメントで説明しようとするよりも、型や変数に理にかなった名前を付けておく方がはるかによい。
コメントを書くときには、コードを読む人のために書こう。つまりコードを理解する必要のある次のコントリビュータ（貢献者）のためだ。親切になろう — 次のコントリビュータ（貢献者）というのはあなた自身のことかもしれないよ!
// もしくは /* */、どちらかの構文を、一貫性を持って使うこと。
// か /* */ のどちらの構文を使ってもよい。しかし、// の方がかなりよくみかける。
どのようにコメントをするのか、どんなスタイルでどこにコメントするのか、一貫性を持たせること。
すべてのファイルには、以下の項目をこの順序で入れておくべきだ。
Copyright 2008 Google Inc.）もともと他人が書いたファイルに大きな変更をしたときには、作者のところに自分の名前を追加しよう。これは、他のコントリビュータ（貢献者）がそのファイルについて質問をしたり、問い合わせ先を知る必要があるときに、とても役に立つ。
各ファイルの先頭（コピーライト宣言と作者に関する行の下）には、ファイルの内容について書いたコメントを入れておくべきだ。
.h ファイルでは通常 、そのファイルで宣言しているクラスがどんなもので、どのように使うのか、概略を説明する。.cc ファイルには詳細実装やトリッキーなアルゴリズムの解説について詳しい情報を入れておくべきだ。もし.h を読む人にとって実装詳細やアルゴリズムの解説が役に立つと思うのであれば、.h に入れておいても構わない。ただし .cc ファイルには、ドキュメントが .h にあることを明記しておくこと。
.h と .cc にあるコメントをコピーしてはいけない。コピーするとコメントが枝分かれしてしまうためだ。
クラスの詳細について、すでにファイルの先頭で説明しているのであれば、"See comment at top of file for a complete description"（「詳しくはファイル先頭のコメントを参照」）と記載しても構わないが、必ず何らかのコメントを入れておくこと。
もしクラスが想定している同期があるのであれば、それについて書いておこう。もしクラスのインスタンスが複数のスレッドからアクセスされる可能性があるのなら、マルチスレッドの利用に関するルールや不変条件が明記してあるか、十分注意すること。
すべての関数宣言には、その関数が何をするもので、どうやって使うのかを説明するコメントをその関数の直前に入れておくべきだ。このコメントは命令調（「ファイルをオープンしろ」）ではなく説明調（「ファイルをオープンする」）にしておくべきだ。コメントは関数について説明するものであって、関数が何をしているのかを説明するものではない。一般的に宣言のコメントは、関数があるタスクをどのようにやっているかを説明するものではない。これは関数宣言ではなく関数定義のコメントに入れておくべきだ。
関数宣言のコメントで言及すべきもの。
NULL になるおそれがあるかどうか。
以下に例を挙げよう。
不必要に冗長にしたり、完璧に明確に記述しようとしてはいけない。以下のように「さもなければ false を返す」と書く必要はない。これは書かなくてもわかることだ。
コンストラクタとデストラクタにコメントを入れるときには、コードを読む人は何のコンストラクタとデストラクタであるかわかっていることを覚えておこう。「オブジェクトを破棄する」のようなコメントには意味がない。コンストラクタがその引数をどう処理するのか（例えばそれらにポインタのオーナーシップがあるなら）、デストラクタは何を解放するのか、といったことをコメントに入れよう。ささいなことであれば、コメントに入れなくてもいい。デストラクタにヘッダコメントがないことはかなりよくあることだ。
関数定義には、その関数がやっていることと、トリッキーなところを説明するコメントを入れておくべきだ。例えば、関数定義には、使っているコーディングテクニックを説明するコメントを入れておいたり、処理ステップの概要を説明したり、なぜ別の案ではなくその実装方法を選んだのかを説明しよう。例えば、なぜ関数の前半でロックを取得しなければならず、後半はその必要がないのか説明するとよい。
.h や、どこかの関数宣言のコメントを繰り返すだけではいけないことに注意しよう。その関数が何であるかを簡単に要約するのもよいが、コメントの重要なポイントは、どのようにしてそれをやるのか、というところにあるべきだ。
クラスデータメンバには（インスタンス変数やメンバ変数と呼ばれることがある）、何のために使われるのかを説明するコメントを入れておくべきだ。変数が NULL や -1 といった特別な意味のある値を番人として扱うときには、それについて明記しておこう。例:
データメンバについて、グローバル変数にはすべて、それが何であり何のために使われるのかを説明するコメントを入れておくべきだ。例:
トリッキーであったり複雑なコードブロックがあれば、その直前にコメントを入れておくべきだ。例:
わかりにくい行には、行末にコメントを入れておくべきだ。行末のコメントは、コードからスペース2つ分、空けておくべきだ。例:
そのコードが何をしているのかを説明しているコメントと、関数が戻るときには既にエラーがログに記録されていることについて述べているコメントがあることに注意しよう。
コメントが複数行になるときには、たいていの場合、一列に並べると読みやすくなる。
関数に NULL やブーリアン、リテラル整数値を渡すときには、それが何かをコメントに書いたり、定数を使うことで自己文書化したコードにすることを検討するべきだ。例えば、以下を比べてみよう。
次のようにする:
あるいは、代わりに、定数や自己文書化した変数を使ってもよい:
コードそのものを説明しようとしてはいけない。あなたよりもC++のことをよく知っている人がコードを読んでいるのだと考えよう。たとえ、相手があなたのやろうとしていることを知らなくてもだ。
コメントは通常、1つの完結した文章として書くべきだ。適切に大文字を使って、文末にはピリオドを付けること。コードの末尾に入れるときなど、コメントが短くなればなるほど形式が失われる場合が多い。しかし、スタイルには一貫性を持つべきだ。完結した文章の方が読みやすいし、コメントが完結していると、未完成の思い付きでないことをある程度保障してくれる。
コードレビュアーから、セミコロンを使うべきところでカンマを使っている、と指摘されるとイライラするが、ソースコードの明確さ、読みやすさを高いレベルで維持することは極めて重要なことだ。句読点や綴り、文法が適切であることは、それを実現する助けになる。
TODO コメントは、一時的なものや、短期的な解決策、その場しのぎの不完全なところに使うこと。
TODO には、すべて大文字からなる TODO という単語を使い、その後に名前やメールアドレスといった識別子を括弧で囲んだものを入れておくべきだ。コロンはあってもなくてもよい。名前やメールアドレスを入れるのは、TODO の書式に一貫性を持たせて、コメントを追加した人を探せるようにするためだ（その人に頼めばさらに詳しく教えてもらえるだろう）。TODO は書いた人が自分で修正することを約束するものではない。
もし TODO が「将来の日付に何かする」という形式であれば、具体的な日付が入っているか（「2005年11月までに修正」）、もしくは具体的なイベントが入っているか（「すべてのクライアントがXMLレスポンスを処理できるようになったらこのコードを削除すること」）を確認しよう。
コーディングスタイルや書式というものは、かなりいい加減なものではあるが、みんなが同じスタイルを使うとプロジェクトはわかりやすくなる。書式のルールに合意してくれない人もいるだろう。慣れるまでに時間がかかるルールもあるだろう。それでも、プロジェクトのコントリビュータ全員が同じスタイルルールに従うことは重要だ。これにより、全員のコードが読みやすく理解しやすいものになるためだ。
コードを正しい書式にするのに役立つよう、私たちは Emacs用の設定ファイルを用意した。
このルールには賛否両論あると思うが、すでに既存のコードのほとんどがこれを守っている。そして、私たちは一貫性のあることが重要だと思っている。
80文字を最大とする。
例外: コメント行に80文字を超えるコマンド例やURL文字列が含まれる場合は、簡単にカット＆ペーストできるよう、80文字を超えても構わない。
例外: #include 文に、80カラムを超える長いパスが含まれる場合 。ただし、こんなものが必要にならないようにしよう。
例外: #define ガードは最大長を超えても気にする必要はない。
ユーザに表示するテキストをソースコードにハードコードしてはいけない。たとえ、それが英語であったとしてもだ。そのため、非ASCII文字を使うことはほとんどないはずだ。しかし、非ASCII文字をコードに入れると都合がよい場合もある。例えば、外部からのデータファイルをパースするコードの場合、非ASCII文字をデータファイルのデリミタとしてハードコードしておくのはよいかもしれない。さらによく見かけるのは、（ローカライズの必要はない）ユニットテスト用のコードに、特定の非ASCII文字が含まれている場合だ。このときにはUTF-8を使うべきだ。UTF-8であれば、ASCII以外の文字を処理できるたいていのツールで解釈可能だ。
Hexエンコーディングを使っても構わない。これを使うと読みやすくなる場合もある。例えば、"\xEF\xBB\xBF" はUnicodeの ゼロ幅改行なし空白文字を意味しているが、ソースコードにそのままUTF-8で書いても見ることができない。
インデントにはスペースを使う。コードにはタブを使ってはいけない。 タブキーを押したときにはスペースが入力されるよう、エディタを設定しておこう。
関数は次のようになる:
長すぎて1行に収まらないときには、次のようにする:
最初のパラメータでさえも1行に収まらないときには、次のようにする:
注意すべきポイント:
関数が const であれば、const キーワードは最後のパラメータと同じ行に書くべきだ:
未使用のパラメータがあれば、関数定義にある変数名をコメントアウトしておくこと:
関数呼び出しは次のような書式になる:
もし引数が1行に収まらなければ複数行に分割して、2行目以降は最初の引数で整列させるべきだ。開き括弧の後や閉じ括弧の前にスペースを入れてはいけない:
関数に引数がたくさんある場合、コードが読みやすくなるのであれば、引数を1行ごとに書くことを検討しよう:
関数シグニチャが長すぎて、最大の行の長さに収まらないときには、引数をすべて2行目以降に書いても構わない:
else キーワードは新しい行にする。
基本的な条件文には、2つの書式が許されている。1つは括弧と条件との間にスペースを入れるもので、もう1つはスペースを入れないものだ。
よく見かけるのは、スペースを入れない書式の方だろう。どちらでもいいのだが、一貫性を持たせること。もし既存のファイルを変更しているのであれば、そこで使われている書式を使おう。もし新しくコードを書いているのであれば、そのディレクトリやプロジェクトの他のファイルで使われている書式を使うこと。よくわからなくて、個人的な好みがないのであれば、スペースを入れないでおこう。
お好みで括弧の中にスペースを入れても構わない:
if と開き括弧との間には、必ずスペースを1つ入れなければならないことに注意しよう。中括弧を使うときには、閉じ括弧と中括弧との間にもスペースを1つ入れなければならない。
もしその方が読みやすいのであれば、短い条件文を1行にまとめて書いても構わない。ただし、その行が簡潔であり、else 節がないときにだけ許される。
if文に else があるときには許されない:
一般に、1行だけの文に中括弧を付ける必要はないが、中括弧を使うのが好みであればそうしても構わない。複雑な条件や文を含むような条件文やループ文の場合、中括弧を使った方が読みやすいかもしれない。if には必ず中括弧を付けなければならない、としているプロジェクトもある。
しかし、1つのif-else文中で中括弧を使っているところがあれば、それ以外のところでも中括弧を使わなければならない。
{} か continue を使うべきだ。
switch の case ブロックには中括弧を付けてもよいし、付けなくてもよい。もし中括弧を付けるのであれば、以下のようにするべきだ。
条件が列挙値でないときには、switch文には必ず default ケースを入れておくべきだ（列挙値の場合には、値が処理されないおそれがあるということを、コンパイラが警告してくれる）。もし default ケースが起こり得ないときには、単に assert を書いておこう:
空ループの本体には、{} や continue を使うべきだ。セミコロンだけにするべきではない。
ポインタとリファレンス表現の正しい書式の例を挙げておく:
以下に注意すること:
* や & の後ろにスペースを入れない。
ポインタ変数やポインタ引数を宣言するときには、アスタリスクを型のそばに置いてもいいし変数名のそばに置いてもよい:
ファイル内では一貫性を持たせるべきだ。既存のファイルを変更するときには、そのファイルのスタイルに従うこと。
この例では、論理積オペレータを常に行末に置いている:
&& 論理積オペレータはいずれも行末にあることに注意しよう。余分な括弧を入れても構わない。うまくやれば非常に読みやすくなる。
return 式を括弧で囲んではいけない。
戻り値は括弧で囲むべきではない。
= を使ってもよいし、() を使ってもよい。
初期化には、= を使ってもよいし、() を使ってもよい。以下はすべて正しい書き方になる:
たとえインデントされたコードの本体の中にあっても、プリプロセッサディレクティブは行の先頭から書き始めるべきだ。
public、protected、private の各セクションはこの順序で書くこと。そして、これらのキーワードはスペース1つでインデントすること。
クラス定義の基本となる書式は、次のようになる（ここにはコメントを入れていないが、どんなコメントが必要かについては、クラスのコメントを参照）。:
注意すべきこと:
public:、protected:、private: といったキーワードは、スペース1つでインデントするべきだ。
public セクションが最初にきて、その後に protected、そして最後に private セクションがくるようにするべきだ。
イニシャライザリストには、2つの書式が許されている。
あるいは、
名前空間内では余分なインデントをしないこと。例えば次のようにすること:
名前空間内では余分なインデントをしてはいけない:
ネストされた名前空間を宣言するときには、名前空間ごとに1行とすること。
行末に空白が入っているとき、他の人がもともとあった行末の空白を削除して、同じファイルを編集してマージしようとすると、余計な作業が発生する場合がある。そのため、行末に空白を入れてはいけない。もし行末に空白のある行を変更しているのなら、その空白を削除してしよう。あるいは、クリーンナップ作業中に削除してしよう（できれば誰もそのファイルで作業をしていないときに）。
これはルールというよりも原則だ。必要のない空行を入れてはいけない。具体的に言うと、関数と関数の間に1行もしくは2行以上の空行を入れてはいけない。関数を空行で始めてはいけないし、空行で終わってもいけない。関数内で空行を使うときには厳選すること。
基本原則: コードが1画面にうまく収まるほど、プログラムの制御フローが追いやすくなり、理解しやすくなる。言うまでもないことだが、コードが密集しすぎても広がりすぎても、読みやすくはならない。自分で判断しよう。しかし、一般的には、垂直方向の空白の使用は最小限にすること。
関数を空行で始めてはいけないし、空行で終わってもいけない:
ブロックを空行で始めてはいけないし、空行で終わってもいけない:
ここに記載したコーディング規約は必須のものだ。しかし、どんな優れたルールにも、時には例外がある。そうした例外について、ここで説明しよう。
このスタイルガイドにあるルールではなく、別のスタイルガイドに従って書かれたコードに手を入れることもあるだろう。そうした場合には、ローカルなコード規約と一貫性を持たせるために、このガイドにあるルールから逸脱する必要があるかもしれない。もし、疑問を感じるのであれば、そのコードの原作者や現在の責任者に尋ねよう。一貫性には、ローカルな一貫性も含んでいることを忘れないようにしよう。
これまで蔓延しているWindowsスタイルを使っていたのなら、このガイドラインを忘れているかもしれない。もう一度言っておく必要があるだろう。
iNum という名前を付けるなど）。Googleの命名規約に従い、ソースファイルには .cc という拡張子を付けること。
DWORD や HANDLE といったものだ。Windows API関数を呼び出すときには、こうした型を使っても全然構わないし、むしろ使うことを推奨する。ただし、できるだけ基本となるC++の型を使うようにすること。例えば、LPCTSTR ではなく const TCHAR * を使うようにしよう。
#pragma once を使ってはいけない。その代わりに、標準的なGoogleのインクルードガード（#define ガード）を使おう。インクルードガードに使うパスは、プロジェクトツリーのトップに対する相対パスにしておくべきだ。
#pragma や __declspec といった非標準の拡張を使ってはいけない。__declspec(dllimport) や __declspec(dllexport) は使っても構わない。しかし、DLLIMPORT や DLLEXPORT といったマクロを通して使うようにしよう。こうしておくと、簡単に無効にすることができる。
とはいえ、Windowsの場合には、時々破らざるを得ないルールがいくつかある。
_ATL_NO_EXCEPTIONS を定義しておくべきだ。STLを使うときにも例外を無効にできるかどうか調べるべきだが、もしできないのならコンパイラで例外を無効にすればよい。（これはSTLをコンパイルするためだけだということに注意しよう。例外を処理するコードを自分で書くべきではない。）
StdAfx.h や precompile.h という名前になっている。他のプロジェクトとコードを共有しやすくするため、ファイルを明示的にインクルードするのではなく（precompile.ccの中を除く）、/FIコンパイルオプションを使って自動的にファイルがインクルードされるようにしよう。
resource.h という名前にして、マクロだけが含まれるようにする。内容については、このスタイルガイドに従う必要はない。
常識を働かせよう、そして、一貫性を持たせよう。
ちょうどコードを書いているところなら、数分かけてまわりのコードを調べてみて、スタイルを決めよう。もし if 節のまわりに空白があるなら、あなたもそうすべきだ。もしコメントがスターで囲まれた小さなボックス状になっているなら、あなたのコメントもそうしよう。
スタイルガイドラインがあるということは、コーディングに共通のボキャブラリがあるということだ。ガイドラインがあるおかげで、どうやって話すかではなく、何を話すかに集中できるようになる。このガイドラインでは、全体的なスタイルに関するルールについて説明した。これでボキャブラリについてはわかったはずだ。ただし、ローカルなスタイルも重要だ。あなたの書いたコードが、まわりにある既存のコードと全然違っているように見えてしまうと、コードを読む人は不連続さを感じて、リズムが狂ってしまう。これは避けるようにしよう。
OK、コードの書き方についてはもう十分だ。コードを書く方がずっとおもしろい。さあ、楽しもう！
Revision 3.146
Benjy Weinberger