コード整形にはclang-formatがいいらしい
→ベーススタイルの１つとして、LLVM coding standardsがある
→先進的な感じに憧れるが、日本語資料が無い
ということで、LLVM coding standardsを翻訳してみました。
LLVM3.9.1版のドキュメントを元にしています。
LLVMコーディング標準
目次
- はじめに
-
言語、ライブラリ、および標準
- C++標準のバージョン
- C++標準ライブラリ
- 利用するC++11言語とライブラリの機能
- その他の言語
-
機械的なソースの問題
- ソースコードのフォーマット
- コメント
- ファイルのヘッダ
- クラスの概要
- メソッド情報
- コメント書式
- ドキュメンテーションコメントでのDoxygenの使用
- #includeの形式
- ソースコードの幅
- タブの代わりにスペースを使う
- コードインデントの一貫
- ラムダはコードブロックと同様に整形
- ブレース初期化子リスト
- コメント
- 言語とコンパイラの問題
- コンパイラ警告はエラーと同様に扱う
- 移植可能なコードを書く
- RTTIや例外を使わない
- 静的コンストラクタを使わない
- classとstructキーワードの使用について
- ブレース初期化子リストはコンストラクタ呼び出しに使わない
- コードを読みやすくするためにauto型推論を使う
- autoでの不必要なコピーに注意
- ソースコードのフォーマット
-
スタイルの問題
- 高位の問題
- 公開ヘッダファイルはモジュール
- #includeは最低限に
- 「内部」ヘッダは非公開
- 早期終了とcontinueでコードをシンプルに
- return後にelseを使用しない
- Predicateはループから関数へ
- 低位の問題
- 型、関数、変数、および列挙子への適切な命名
- アサートたっぷり
- using namespace stdを使わない
- ヘッダ内クラスは仮想メソッドアンカーを提供する
- 列挙型を網羅したswitchにdefaultを使わない
- ループで毎回
end()を評価しない - #include 禁止
- raw_ostreamの使用
- std::endlを避ける
- クラス定義内の関数定義で
inlineを使わない
- 微視的詳細
- 括弧の前にスペース
- 前置インクリメントの選好
- 名前空間のインデント
- 無名名前空間
- 高位の問題
- See Also
はじめに
この文書は、LLVMのソースツリーで使用されているいくつかのコーディング標準を記述しようと試みたものです。コーディング標準は、すべての事例で従うべき絶対的な要件とみなされるべきではありませんが、（LLVMのような）ライブラリベースの設計に従った大規模なコードベースでは特に重要となります。
この文書は、いくつかの機械的な書式設定の問題、空白やその他「微視的な詳細」のための指針を提供しますが、これらは固定的な基準ではありません。常に以下のゴールデンルールに従ってください。
あなたが既存のコードを拡張、強化、または修正する場合は、すでにソースが用いているスタイルを踏襲してください。
注意：一部のコードベース（例えば libc++）はコーディング標準から逸脱する本当に良い理由があります。例えば libc++ の場合、命名およびその他の規則は、C++標準で定められています。もしここの標準から逸脱する特定の正当な理由があると思われる場合は、ぜひそれをLLVM-devメーリングリストへ挙げてください。
コードベースにはいくつかの逸脱も含まれます（例えば、命名規則）。これらは比較的新しく、またコードベースへの格納前に多くのコードが作成済みであったためです。私たちの長期的な目標はコードベース全体が規則に従うことですが、既存コードを大きく再フォーマットするパッチは望んでいません。何か別の修正を行う際に、併せてそのクラスのメソッドの名前を変更することは妥当です。ただし、機能変更と再フォーマットはコミットを分けてください。
これらのガイドラインの究極の目標は、私たちの共通のソースベースの可読性と保守性を高めることです。もし含まれるべきトピックの案があれば、ぜひChrisまでメールください。