自分で見返す用にまとめました。
印刷してラミネートして、いつでも参照できる状態にすると尚よしです。
リーダブルコードチェックリスト
1章 コードの可読性
- コードは理解しやすくなければならない。(p2)
- コードは他の人が最短期間で理解できるように書かなければならない。(p4)
- コードは短くしたほうがいい。だけど「理解するまでにかかる時間」を短くするほうが大切(p4)
2章 基本的な命名規則
- 明確で具体的で情報の備わった変数名を使用することで、変数名を読んだだけで中身がどんなものか把握できるようにする(原則)(p10,16,19)
- tmp,retval,resultなどの汎用的で抽象的な変数は避ける(原則)(p12)
- 変数名が長くても意味が伝わればいい、省略して解読に時間がかかるよりマシ(原則)(p23)
- ただし、i j k などはループの変数として理解できるため使ってもよいこととする(例外)(p14)
- stringをstr、documentをdocと省略するのは問題ないが、チーム独自の省略規則はやめよう(例外)(p15)
- スコープが小さければ短い名前でもいい(例外)(p23)
// 明確で具体的で情報の備わった変数名〜
// 上から順に、明確な変数名、具体的な変数名、情報の備わった変数名
| 単語 | 代替案 |
|---|---|
| send | deliver,dispatch,announce,distribute,route |
| find | search,etract,locate,recover |
| start | launch,create,begin,open |
| make | create,set up,build,generate,compose,add,new |
server_can_star()よりもcan_listen_on_port()の方が明確で具体的
| 状況 | 変数名 | 改善後 |
|---|---|---|
| passwordはプレインテキストなので、処理をする前に暗号化すべきである。 | password | plaintext_password |
| ユーザーが入力したcommentは 表示する前にエスケープする必要がある。 | comment | unescaped_comment |
| htmlの文字コードをUTF-8に変えた。 | html | html_utf8 |
| 入力されたdataをURLエンコードした。 | data | data_urlenc |
3章 誤解されない名前
- 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する(p30)
- 限界値を示す変数に min_ max_を使っているか。(p31)
- 範囲を示す変数に first_ last_を使っているか。(p32)
- 包括的範囲には begin_ end_ を使っているか。(p32)
- getXXXXメソッドをアクセッサー以外で定義していないか。(p34)
4章 美しさ
- インデントが整っており見やすいコードになっているか。(p50)
- 正しさより一貫性。(p49,52)
5章 コメントのルール(What)
価値のあるコメント(自身の考え)
-
定数にはコメントが書かれているか。
THREAD_NUM = 8だけだとデフォルトが8になった経緯が不明。(p62) - クラスの使用方法など高レベルのコメントが必要なファイルには、ファイルの先頭にコメントが書かれているか。(p66)
- どのような経緯でコードが実装されたかを記載する(監督コメンタリー)(p60)
- 時間やスキルの兼ね合いから発生するコードの欠陥にコメントをいれる(言い訳)(p61)
| 記法 | 典型的な意味 |
|---|---|
| TODO: | あとで手をつける |
| FIXME: | 既知の不具合があるコード |
| HACK: | あまり綺麗じゃない解決策 |
| XXX: | 危険！大きな問題がある |
価値のあるコメント(理解の促進)
- 第三者がコードを読んで疑問に思う点、間違って使う可能性を前もって想像し、コメントする(p63)
- メソッドや処理の塊に対する要約コメント(p66)
- 全体像に対するコメント(p66)
価値のないコメント
- 処理の内容など、コードを読めば分かることをコメントしない(p57) //ここはコンストラクタ
6章 正確で簡潔なコードの書き方(How)
- 情報密度の高い言葉を使う(専門用語、コンピュータ用語)(p78)
- 入出力のコーナーケースには実例を使う(ただし実例は慎重に選ぶ)(p74)
7章 制御フローを読みやすくする
- ヨーダ記法を使用していないか。(p85)
- 三項演算子を使った結果、コードが理解しずらいものになっていないか。(p88)
- do~whileループを使用していないか。(p89)
- 関数内で早めに処理が抜けられるものはreturnで適切にガード節が作られているか。(p91)
- ifのネストが深くなっていないか。(p93)
8章 巨大な式を分割する
- 説明変数を使って改良できるコードが残っていないか。(p100)
- 要約変数を使って改良できるコードが残っていないか。(p100)
- 短絡評価を悪用、乱用していないか。(p102)
9章 変数と読みやすさ
- ループ処理の中で不要な中間結果を保持する変数を使用していないか。
- ループ処理の中で不要な制御変数を定義して使用していないか。
- グローバルなスコープが必要ないグローバル変数を定義していないか。
- クラス変数のスコープが必要ないクラス変数を定義していないか。
- JavaScriptで変数がグローバル領域にはみ出していないか。
- 古いC言語のルールに沿って意味もなく変数の定義を全て関数の先頭に書いていないか。
- 変更の必要ない変数には積極的にfinalがついているか。(C++, java)
10章 無関係な下位問題を抽出する
- メソッドの抽出が必要なコードは残っていないか。
11章 一度に一つのことを
- ひとつのメソッド内に複数のタスクが書かれていないか。
- メソッド名を逸脱した複数のタスクがひとつのメソッド内に書かれていないか。
12章 コードに思いを込める
なし
13章 短いコードを書く
- 標準APIにある機能をオレオレ実装していないか。
- 広く使われている外部ライブラリ(Apache CommonsやBoost)にあるような機能をオレオレ実装していないか。
14章 テストと読みやすさ
- テストコードが理解しづらいものになっていないか。
15章
なし