リーダブルコードを読んで、学びになった箇所についてメモ的にストックしていきます。(随時更新)
モチベーション
- チーム開発における生産性の向上のために可読性高いコードを書くことの重要性を体感したため
- コーディングルールに一定の基準を持つことで迷いなくコーディングをしたいと思ったため
1章. 理解しやすいコード
-
読みやすさの基本定理
- 優れたコードとは、他の人が最短時間で理解できるコードである。
- また、この「他人が理解するまでにかかる時間」と「設計のし易さ」「テストのし易さ」などは、基本的に競合しないため、コーディングにおいては最短時間で理解できるコードが正義である。
2章. 名前に情報を詰め込む
-
明確な単語を選ぶ
- ex. 同じ「入手する」でも、もしインターネットから取ってくるのであれば、
GetPage(url)
よりもFetchPage(url)
の方が分かり易い。
- ex. 同じ「入手する」でも、もしインターネットから取ってくるのであれば、
-
汎用的な名前を避ける
- 一時保存の目的以外での、
tmp
,foo
,bar
といった空虚な名前での命名は怠慢である。サボらずエンティティの値や目的を表した名前を選ぶ。
- 一時保存の目的以外での、
-
変数名に情報を追加する
- 知らせるべき情報があれば「単語」を変数名に追加する。
- ex1. 値の単位:
start
よりもstart_ms
の方が明確 - ex2. データ型:
html
よりもhtml_utf8
の方が明確
- ex1. 値の単位:
- 知らせるべき情報があれば「単語」を変数名に追加する。
-
名前の長さを決める
- 変数のスコープが小さいとき
- 変数名に情報を詰め込む必要はない(=変数の型や目的をすぐに把握できる)ため、とにかく短くしていい。
- 変数のスコープが広いとき
- 変数名に十分に情報を詰め込むことで、意味を明確にする必要がある(=変数の型や目的をすぐに把握できない)ため、短くしすぎてはならない。
- 変数のスコープが小さいとき
-
固有の省略形は使用しない
- 「プロジェクト固有での関数名やクラス名の省略形」は、新しいチームメンバーを怖がらせ得るので、用いない。(=
evaluation
→eval
やdocument
→doc
といった「常識的な省略形」は可)
- 「プロジェクト固有での関数名やクラス名の省略形」は、新しいチームメンバーを怖がらせ得るので、用いない。(=
-
無駄な単語は捨てる
- 必要最小限で伝えるべき。
- ×
ConvertToString()
- ○
ToString()
- ×
- 必要最小限で伝えるべき。
-
フォーマットに情報を込める
- ある種のシンタックスハイライトのように、フォーマットで情報を込めることによって、一目で何なのかが伝わる。
- ex1. クラス名→
CamelCase()
(キャメルケース) - ex2. 変数名→
lower_separated
(アンダーバー区切りの小文字) - ex3. クラスのメンバ変数→、
member_
(お尻にアンダースコア)
- ex1. クラス名→
- ある種のシンタックスハイライトのように、フォーマットで情報を込めることによって、一目で何なのかが伝わる。