リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

第１章　理解しやすいコード

• コードは，理解しやすくなければいけない．
• コードは，他の人(半年後の自分)が最短時間で理解できるように書かなければいけない．

第２章　名前に情報を詰め込む

• 明確な単語を選ぶ．
  → Getではなく，状況に応じてFetchやDownloadなどを使う．
• tmpやretvalなどの汎用的な名前を避ける．
• 具体的な名前を使って，物事を詳細に説明する．
  → ServerCanStart()よりも，CanListenOnPort()の方が明確．
• 変数名に大切な情報を追加する．
  → ミリ秒を表す変数名には，_msをつける．メンバ変数にはm_をつけるなど．
• スコープの大きな変数には，長い名前をつける．
  → スコープが数画面に及ぶ変数に1〜2文字の短い暗号めいた名前をつけてはいけない．短い名前は，スコープが短い変数につけるべき．
• 大文字やアンダースコアをつけて，ローカル変数と区別する．

第３章　誤解されない名前

• 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する．
• 限界値を明確にするには，名前の前にmax_やmin_をつける．

第４章　美しさ

• 一貫性のあるスタイルは，「正しい」スタイルよりも大切．
• 複数のコードブロックで同じようなことをしていたら，シルエットも同じようにする．
• コードの「列」を整列すれば，概要が把握しやすくなる．
• 空行を使って，大きなブロックを論理的な「段落」に分ける．

第５章　コメントすべきことを知る

• コメントの目的は，書き手の意図を読み手に知らせることである．
• コメントすべきで「ない」こと：
  ・コードからすぐに抽出できること．
  ・ひどいコード（例えば，ひどい名前の関数）を補う「補助的なコメント」
  　→ コメントを書くのではなく，コードを修正する．
• 記録すべき自分の考え：
  ・なぜコードが他のやり方ではなくこうなっているのか．
  ・コードの欠陥を TODO: や XXX: などの記法を使って示す． 
  ・定数の値にまつわる「背景」．
• 読み手の立ち場になって考える：
  ・コードを読んだ人が「えっ？」と思うところを予想してコメントをつける．
  ・ファイルやクラスには「全体像」のコメントを書く．
  ・コードブロックにコメントをつけて概要をまとめる．

第６章　コメントは正確で簡潔に

• 関数の動作は，できるだけ正確に説明する．
• インラインコメントを使う．（ Function (/* arg = */ ...) ） 
• 多くの意味が詰め込まれた言葉や表現を使って，コメントを簡潔に保つ．

第９章　変数と読みやすさ

• 邪魔な変数を削除する．
  → 結果をすぐに使うことで，「中間結果」の変数を削除する．
• 変数のスコープをできるだけ小さくする．
  → 変数を数行のコードからしか見えない位置に移動する．
• 一度だけ書き込む変数を使う．
  → 変数に一度だけ値を設定すれば（あるいはconstやfinalなどのイミュータブルにする方法を使えば），コードが理解しやすくなる．

第１０章　無関係の下位問題を抽出する

• プロジェクト固有のコードから，汎用コードを分離する． 
  → あとでコードを再利用できるかもしれない．

第１１章　一度に１つのことを

•  読みにくいコードがあれば，そこで行われているタスクをすべて列挙する．
  → そこには，別の関数やクラスに分割できるタスクはないか？

第１２章　コードに思いを込める

• プログラムの内容を「簡単な言葉で説明する」．
• 問題や設計をうまく言葉で説明できないのであれば，何かを見落としているか，詳細が明確になっていないということ．

第１３章　短いコードを書く

• 不必要な機能をプロダクトから削除する．過剰な機能は持たせない．
• 定期的にすべてのAPIを読んで，標準ライブラリに慣れ親しんでおく．
  → 自作するよりも，最適化された標準ライブラリを使う．

第１４章　テストと読みやすさ

• テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する．
• エラーメッセージを読みやすくする．
• テスト関数に説明的な名前をつけて，何をテストしているのかを明らかにする．

第１５章　「分/時間カウンタ」を設計・実装する

• パフォーマンス速度を比較する．