checklist/c_code_review_checklist.txt

全般
コードは実装が必要なものですか？

オープンソースライブラリなど、広く使われている、あるいは信頼性の高いコードが利用できないか検討しましょう。
コードは動作しますか？

コミット、マージする前に、最低限の動作を確認しましょう。
コードを動作させるための手順は明確ですか？

最低限、コードの実行方法、依存関係をREADME.mdなどに書きましょう。
コードは理解しやすいように記述されていますか？

数ヶ月後の自分が読んでも理解できそうですか？
マジックナンバーが埋め込まれていませんか？
定数化するなど、名称を与えることができないか検討しましょう。
コードは長すぎませんか？

関数（メソッド）が数十行を越える場合、分割できないかどうか検証しましょう。
不要なコードが残っていませんか？

テストコード
テストコードは記述されていますか？

可能な限り記述しましょう。
テストコードの実行結果はグリーン（正常）ですか？

レッド（失敗）なのであれば、その状態で本当にコミットしなければならないのかどうか再考しましょう。
コーディングスタイル / 命名規則
コーディングスタイルは統一されていますか？

コーディング標準（コーディング規約）が制定されている場合、その標準に従っていますか？
例: Python - PEP-8、Google Python Style Guide
例: C++ - Google C++ Style Guide
ネストが深くなりすぎていませんか？

識別子
スペルは正しいですか？

camelCase、PascalCase、snake_caseなど、それぞれの表現と意味は統一されていますか？

名称	別名	代表的な用途
camelCase	lowerCamelCase	Javaの変数名、仮引数名。JavaScriptのプロパティ名。
PascalCase	UpperCamelCase	Java、C++、Rubyのクラス名。
snake_case	underline_style、lower_case、lower_case_with_underscores	Rubyのメソッド名、変数名。
UPPER_CASE	UPPER_CASE_WITH_UNDERSCORES	C言語のマクロ名。Javaの定数名。
単数形、複数形は適切に使い分けられていますか？

tmp、bufferなど、汎用的過ぎる名称は使われていませんか？

より具体的な名称にできないかどうか検討しましょう。
コード内で利用されている名称は統一されていますか？

略語を用いている場合、それは一般的な略語ですか？

略語を用いている場合、それは展開しても十分短い名前ではないですか？

対称的な処理を行っている場合、対称的な名前になっていますか？

セキュリティ
パスワード、秘密鍵などは埋め込まれていませんか？
ファイル
絶対パスが埋め込まれていませんか？

カレントディレクトリに依存したコードになっていませんか？

カレントディレクトリに依存していると、実行する環境を整えるのが大変になります。
スクリプトファイルからの相対パス、何らかの基準パスからの相対パスに書き換えることができないか検討しましょう。
ファイルは適切にクローズされていますか？

コメント
そのコメントは必要ですか？

コメントで補足するより、元のコードをより分かりやすく書き換えることができないか検証しましょう。
コードを自然言語に書き直しただけのコメントになっていませんか？

コメントにはコードで表現できないこと（そのアルゴリズムを採用した理由、など）を記述しましょう。
コメントアウトされたコードは残っていませんか？

データ型
配列であるべきデータですか？
複数の値を渡したいという理由だけで配列が使われていませんか？
タプル、ハッシュ（ディクショナリ）など、他のデータ型を検討しましょう。
コマンド / ツール
適切な終了コードを返していますか？

MakefileやDockerfileでコマンドを呼び出す場合、終了コードが重要な意味を持ちます。
異常を適切に伝えるために、0以外の終了コードを返すことを検討しましょう。
標準出力と標準エラー出力を適切に使い分けていますか？

その他
乱数を使用する場合、シード（種）は適切ですか？
再現性が必要な場合、シードを固定する手段を提供しましょう。