#リーダブルコード適用 チェックリスト
- コーディング初心者はコードを書いた後、コードレビューしてもらう前にこのチェックリストでセルフチェックをする
- (コーディング中級者の)レビューワーはこのチェックリストをチェックつけながらコードレビューをする
- コーディング上級者（もしくはリーダブルコードを暗記してる人）はこのチェックリストは必要ないが、プロジェクトのレビュー運営のポリシーによって使うこともある。
- チェックリストの内容がわからなかった場合はリーダブルコード要約、もしくは「リーダブルコード」自体を読んで確認する。
- 今すぐ直せないコードもあるため全てにチェックがつかないといけないわけじゃない、チェックできなかった理由をレビュー対象者と共有し議論し、改善できる点は今後に活かそう。
- チェックにひっかかった、悪いコードはアンチパターン集としてプロジェクトの大事な資産としてwikiなどに記録して勉強会などで紹介してみよう。
- リーダブルコードは全15章あるため多くても1章5個程度のチェックリストに収める（5個でも全部で75個になるため）
- 「コードが〜〜〜〜であること。」などチェック調の文体にする。
- 言語、フレームワークによってはチェックに沿わないこともある、その場合はチェックリストや別紙にイレギュラーケースを蓄積して後のレビューワーが参照できるようにする。
- コードは理解しやすくなければならない。
- コードは他の人が最短期間で理解できるように書かなければならない。
- tmp,retval,resultなどの汎用的すぎる変数を使っていないか。
- 変数名の英単語を省略して理解しずらいものになっていないか。
- 変数名が長くなるのを恐れて短くしすぎて理解しずらいものになっていないか。
- 限界値を示す変数に min_ max_を使っているか。
- 範囲を示す変数に first_ last_を使っているか。
- getXXXXメソッドをアクセッサー以外で定義していないか。
- インデントが整っており見やすいコードになっているか。
- 意味のないコメントを書いていないか。
- コードから読み取れる事をコメントに書いていないか。
- 定数にはコメントが書かれているか。
- クラスの使用方法など高レベルのコメントが必要なファイルには、ファイルの先頭にコメントが書かれているか。
なし
- ヨーダ記法を使用していないか。
- 三項演算子を使った結果、コードが理解しずらいものになっていないか。
- do~whileループを使用していないか。
- 関数内で早めに処理が抜けられるものはreturnで適切にガード節が作られているか。
- ifのネストが深くなっていないか。
- 説明変数を使って改良できるコードが残っていないか。
- 要約変数を使って改良できるコードが残っていないか。
- 短絡評価を悪用、乱用していないか。
- ループ処理の中で不要な中間結果を保持する変数を使用していないか。
- ループ処理の中で不要な制御変数を定義して使用していないか。
- グローバルなスコープが必要ないグローバル変数を定義していないか。
- クラス変数のスコープが必要ないクラス変数を定義していないか。
- JavaScriptで変数がグローバル領域にはみ出していないか。
- 古いC言語のルールに沿って意味もなく変数の定義を全て関数の先頭に書いていないか。
- 変更の必要ない変数には積極的にfinalがついているか。(C++, java)
- メソッドの抽出が必要なコードは残っていないか。
- ひとつの関数内に複数のタスクが書かれていないか。
- 関数名を逸脱した複数のタスクがひとつの関数内に書かれていないか。
なし
- 標準APIにある機能をオレオレ実装していないか。
- 広く使われている外部ライブラリ(Apache CommonsやBoost)にあるような機能をオレオレ実装していないか。
- テストコードが理解しづらいものになっていないか。
なし