Tom.notes();

Computer Scienceや読書のメモ

リーダブルコード

 

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

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

 

 

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

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

 

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

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

 

第3章 誤解されない名前

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

 

第4章 美しさ

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

 

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

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

 

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

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

 

第9章 変数と読みやすさ

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

 

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

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

 

第11章 一度に1つのことを

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

 

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

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

 

第13章 短いコードを書く

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

 

第14章 テストと読みやすさ

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

 

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

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