ぽっけの技術ブログ

仕事や趣味で日々学んだことを出力していきます。

リーダブルコード、解釈と所感

プログラミング初心者~中級者によくおすすめされているリーダブルコードプログラマ歴3年目にして初めて読んだので、自分なりの解釈と所感を書きます。

www.amazon.co.jp

概要

本書はタイトルの通り、読みやすいコードの重要性とそれをどうやって書くかに焦点を当てた技術書です。
他人(未来の自分も含む)から見て読みやすいコードを書くことによって、コードの再利用や保守をやりやすくするのが目的です。

そしてこの本自体が(たぶん意識して)かなり読みやすく書かれています。
文章がすべて口語体だったりたまに挿絵漫画が挟まったり、初学者でもとっつきやすいようかなり工夫がされています。また1章につき平均13ページと短く、集中力を切らさずに一気に理解してしまえる長さに区切られています。
C++JavaScriptPythonなどの具体的なコードを使って解説しています。しかしコードも使い方も簡潔で、プログラミング言語を1つでも触ったことのある人なら十分理解できるようになっています。

解釈

1章

要約:コードを読みやすくすることが大事。(本書のテーマ)。コードを短くすることではない

2章

要約:「パッと見で意味が分かる」を目的に変数名やメソッド名を付ける方法

  • 変数やメソッドには明確な名前を選んで付ける。メソッドGet○○()よりはFetch○○()やDownload○○()など。
  • tmpを小さいスコープの中で使う、イテレータとしてi,j,kを使うのは問題ない。ただしより適した名前があればそれに変えるべき。
for (let i = 0; i < 9; i++) {
  // ループ中の処理
}
  • 間違えるとまずい変数は変数名に付加情報を付けるといい。start_ms(単位がミリ秒であることを強調)、html_utf8(文字コードUTF-8であることを強調)など。
  • 大きいスコープの変数に無理に省略した短い変数名を付けてはいけない。何の略なのかわからなくなるため。
  • 名前のフォーマット(スネークケースやキャメルケース)に情報を持たせることもできる。見ただけでローカル変数かメンバ変数かわかるようになる、などの利点がある。

3章

要約:他の使用者が誤解しないよう気を付けて名前を付ける

  • 限界値を含めるときはmaxやminを使う。
  • 範囲はfirstとlastを使う。
  • 最初を含むが最後は含まない範囲はbeginとendを使う。
  • ブール値の変数名は頭にis・has・can・shouldを使うといい。否定形の変数名はできるだけ使わない。

4章

要約:一貫性のある美しいコードを書こう。プログラミングの時間のほとんどはコードを読む時間だ

  • 同列なものを並べるときは見た目をそろえる。
  • 空行やコメントを使い、段落やブロックに分けて書く。

5章

要約:他人でも理解できるような適切なコメントを書く

  • コメントを付けるより、できるならコメントなしで理解できるコードを書いた方がいい。
  • どんな考えでこのコードを書いたのか、このブロックはどういう意図のコードかなど、他人に理解してもらうためのコメントを書く。

6章

要約:コメントは正確で簡潔に

  • あいまいな言葉を避け短く書く。
  • メソッドの説明のために、引数と返り値の例を記述してもいい。
  • 簡潔に述べるために、「キャッシュ層」「正規化する」など多くの情報を含む言葉を使うといい。

7章

要約:読みやすいように条件分岐やループを組み立てよう

  • 比較(<,>,==など)は左に調査対象の変化する値を置く。
  • if/elseブロックは以下の並び順を参考にすると読みやすくなる。
    • 条件は否定形より肯定形
    • 単純な条件を先に
    • 目立つ条件を先に
  • 三項演算子(条件 ? a : b)はif/elseとどちらが読みやすいか吟味して使う。
  • do/while文はwhile文に書き換えた方が読みやすいことが多い。
  • ガード節で関数の早くから返すのもいい。
  • gotoは基本的に使わない
  • ループのネストを浅く。早めに返したりcontinueを使って改良できる。

8章

要約:人間は同時に多くのものを考えられないので、巨大な式は分割するべき

  • きれいに1行で書くよりも、変数を増やしてでもわかりやすく書いた方がいい。
  • 論理式をド・モルガンの法則で読みやすくできることも。
not (a or b) <=> (not a) and (not b)
not (a and b) <=> (not a) or (not b)
  • 簡単な問題のはずなのにロジックが複雑になってしまったら、発想を転換すべきだ。もっと簡単な方法がある。
  • 巨大な文になってしまったら、共通の式を抜き出して要約変数にしてみる。

9章

要約:変数を工夫してコードを読みやすく

  • 不要な変数は削除。
  • 変数のスコープを小さくすることで、一度に考えなければいけない変数を減らせる。
    • JavaScriptの「クロージャで包む」など、スコープを小さくするためのテクニックを使用する。
    • PythonJavaScriptではブロック内で定義された変数がその関数全体で参照できてしまうので特に注意。
  • 定義は関数やブロックの先頭で行う必要はない。使う直前がいい。
  • 一度だけ書き込む変数はconstやfinalで定義すると考えることを減らせる。

10章

要約:メソッドの目的と関係ない部分を抽出し、別のメソッドとする。(≒無関係の下位問題を抽出する

  • 結果、メソッドには本質的なロジックを扱うコードだけが残る。
  • 大切ではない詳細はユーザーから隠し、大切な詳細は目立つようにする。(14章に書いてあるが、本章の内容に近い)

11章

要約:一度に一つのことを行うようコードを書く

  • 複雑なタスクは整理し、どのようなタスクを組み合わせているかを考え、分割していく。

12章

要約:コードを書くときは、複雑な考えを簡単な言葉で伝えるような意識をもつ

  • ややこしくなってしまったロジックは簡単な言葉で説明してみてから書きなおすといい。自然で簡潔なコードにできる。
  • ラバーダッキングもこれに近い手法。

13章

要約:コードは短いか、何も書かれていない方がいい

  • 書いたコードのテストや保守、文書化などの労力が大きいため。
  • 問題に対して最小の解決法を見つけ出す。
    例:狭い範囲の距離計算機能に、地球の曲率や日付変更線の計算は必要ない。
  • たまに標準ライブラリを読んで把握しておくと、楽な実装を思いつきやすい。

14章

要約:これまでの内容を使い、すっきりと効果的なテストを書こう

  • エラーメッセージはわかりやすく。
  • テスト入力値は綺麗で単純な値を選ぶ。
  • テストに名前を付ける。Test_<関数名> など。
  • 最初からテストしやすいようにコードを書いているといいコードが書ける。クラスやメソッドがよく分割され、グローバル変数が少なくなる。

15章

要約:これまでの内容を使い、時間に関するカウンタを作成する

  • 集大成。これまでの内容(問題の抽出や分割など)を、実際の設計に役立てる様子を筆者が見せてくれる。

所感

読みやすいコードを書く利点や具体的な方法が簡潔に述べられ、全編通して理解しやすかったです。
プログラミングをしていると経験則として身につく「ここはメソッド分けた方がいいな」「分岐条件整理した方がいいな」といったことが理論立てて解説されているので、改めて自分のコーディングを見直すいい機会になりました。
初めてコードを書く方はこれからの指標にできるし、経験者も自分の思考を見直したり悪いクセを矯正したりできる、様々な方にお勧めできる良書でした。