リーダブルコード要約

リーダブルコードを読んで、学びになった箇所についてメモ的にストックしていきます。（随時更新）

モチベーション

• チーム開発における生産性の向上のために可読性高いコードを書くことの重要性を体感したため
• コーディングルールに一定の基準を持つことで迷いなくコーディングをしたいと思ったため

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

• 読みやすさの基本定理
  • 優れたコードとは、他の人が最短時間で理解できるコードである。
  • また、この「他人が理解するまでにかかる時間」と「設計のし易さ」「テストのし易さ」などは、基本的に競合しないため、コーディングにおいては最短時間で理解できるコードが正義である。

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

• 明確な単語を選ぶ
  • ex. 同じ「入手する」でも、もしインターネットから取ってくるのであれば、GetPage(url)よりもFetchPage(url)の方が分かり易い。
• 汎用的な名前を避ける
  • 一時保存の目的以外での、tmp, foo, barといった空虚な名前での命名は怠慢である。サボらずエンティティの値や目的を表した名前を選ぶ。
• 変数名に情報を追加する
  • 知らせるべき情報があれば「単語」を変数名に追加する。
    • ex1. 値の単位：startよりもstart_msの方が明確
    • ex2. データ型：htmlよりもhtml_utf8の方が明確
• 名前の長さを決める
  • 変数のスコープが小さいとき
    
    • 変数名に情報を詰め込む必要はない（＝変数の型や目的をすぐに把握できる）ため、とにかく短くしていい。
  • 変数のスコープが広いとき
    • 変数名に十分に情報を詰め込むことで、意味を明確にする必要がある（＝変数の型や目的をすぐに把握できない）ため、短くしすぎてはならない。
• 固有の省略形は使用しない
  • 「プロジェクト固有での関数名やクラス名の省略形」は、新しいチームメンバーを怖がらせ得るので、用いない。（＝evaluation→evalやdocument→docといった「常識的な省略形」は可）
• 無駄な単語は捨てる
  • 必要最小限で伝えるべき。
    • × ConvertToString()
    • ○ ToString()
• フォーマットに情報を込める
  • ある種のシンタックスハイライトのように、フォーマットで情報を込めることによって、一目で何なのかが伝わる。
    • ex1. クラス名→CamelCase()（キャメルケース）
    • ex2. 変数名→lower_separated（アンダーバー区切りの小文字）
    • ex3. クラスのメンバ変数→、member_（お尻にアンダースコア）

参考文献

• リーダブルコード