【技術書まとめ23】リーダブルコード

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第23弾です。

今回は、リーダブルコード  を読みました。

もはや説明不要の名著ですが、良いコードを書くための原則を分かりやすく、そして簡潔に解説している本です。

200ページ程度でサクッと読めましたが、気づきがとても多かったです。

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

1章 理解しやすいコード

• コードは「他の人が最短時間で理解できるように」書く

 

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

• tmpなどの汎用的な名前が単なる怠慢で使われていることも多い。いい名前が思いつかなかったらfooのような意味のない名前を使いたくなってしまうが、少しでも時間を使って名前を考える習慣をつけるようになればすぐに命名力は高まる

• 抽象的な名前よりも具体的な名前を使う

• 単位やセキュリティなどの重要な属性を名前に追加するのも有効（例 ミリ秒を表す変数名には、後ろに _ms をつけるなど）

 

3章 誤解されない名前

• 誤解される可能性がある名前をつけない。「他の意味と間違えられることはないだろうか」と自問自答する

• 上下の限界値を決めるときは、max_ や min_ を前につけるとよい

• ブール値に名前をつけるときは、それがブール値だとわかるように is や has などを使う

 

4章 美しさ

• 複数のコードブロックで同じようなことをしていたら、ぱっと見て分かるようにシルエットも同じようなものにする

• コードを縦に揃えて楽に読めるようにする

 

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

• コメントの目的は、書き手の意図を読み手に伝えること

• コードからすぐにわかることをコメントに書かない

• コメントよりも自己文書化された適切な名前（関数名、変数名）をつけるべき

• 優れたコメントは、コードを書いた考え（なぜコードが他のやり方ではなくこうなっているのかなど）を記録するためのもの

• 定数を定義するときに、その定数が何をするのか、なぜその値を持っているかという背景をコメントするとわかりやすくなるケースが多い

• 読み手の立場になって考え、質問されそうなこと、ハマりそうな罠についてコメントする

 

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

• 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける

• 入出力の実例をコメントに書いておくことは千の言葉に等しい

 

7章 制御フローを読みやすくする

• ネストの深いコードは理解しにくい。ネストが深くなると、読み手は「精神的スタック」に条件をプッシュしなければならない

• 「失敗ケース」をできるだけ早めに関数から返すことで、ネストを削除できることが多い

• 比較を書くときには、変化する値を左に、より安定した値を右に配置する

• If/elseのブロックは適切に並び替える。一般的には、肯定系・単純・目立つものを先に処理する

 

8章 巨大な式を分割する

• 人間は一度に3〜4つの「もの」しか考えられないので、コードの式が大きくなれば、それだけ理解が難しくなる

• 大きな式の値を保持する説明変数を導入すれば、巨大な式を分割でき、コードを文書化することができる

 

9章 変数と読みやすさ

• 変数のスコープを縮めると読みやすくなる

• 変数が絶えず変更され続けると現在値の判断が難しくなりコードが理解しにくくなるので、変数は一度だけ書き込むようにするとよい

 

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

• 以下のステップで無関係の下位問題を見つけて抽出する
• • 関数やコードブロックを見て「このコードの高レベルの問題は何か？」を自問する

• • コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」を自問する

• • 無関係の下位問題を解決しているコードが相当量あるば、それらを抽出して別の関数にする

• 関数は、小さく独立したものになっていれば、機能追加・エッジケースの処理などが楽にでき、読みやすくなる

• プロジェクト固有のコードから汎用コードを分離する。ほとんどのコードは汎用化できる

 

11章 一度に1つのことを

• 一度に1つのタスクをするためには、まずコードが行なっているタスクを全て列挙し、タスクをできるだけ異なる関数に分割するとよい

• 最も大切なのは、プログラムが行なっていることを正確に説明すること

 

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

• 誰かに複雑な考えを伝えるときには、細かいことまで話しすぎると相手を混乱させてしまう。自分よりも知識が少ない人が理解できるような「簡単な言葉」で説明する能力が大切。これには、自分の考えを凝縮して、最も大切な概念にすることが必要となる。これは誰かに理解してもらうだけでなく、自分の考えをより明確にすることにもなる

• コードというのは、プログラムの動作を説明する最も大切な手段である。つまり、コードも簡単な言葉で書くべき。問題や設計をうまく説明できないのであれば、何かを見落としているか、詳細が明確になっていないということ。プログラム（あるいは自分の考え）を言葉にすることで明確な形になる

• 以下のステップでコードを明確にすることができる
• • コードの動作を簡単な言葉で同僚にもわかるように説明する

• • その説明の中で使っているキーワードやフレーズに注目する

• • その説明に合わせてコードを書く

 

13章 短いコードを書く

• 自分で書いたコードであれば、全ての行をテストして保守しなければいけない。ライブラリの利用や機能の削除をすることで、時間の節約をしたり、コードを簡潔に維持したりできる

• プロジェクトが成長しても、コードをできるだけ小さく軽量に維持するために、以下のことをすべき
• • 汎用的なユーティリティコードを作って、重複コードを削除する

• • 未使用のコードや無用の機能を削除する

• • プロジェクトをサブプロジェクトに分割する

 

14章 テストと読みやすさ

• 他のプログラマが安心してテストの追加や変更ができるように、テストコードは読みやすくするべき

• 一般的な設計原則として、大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする

• テストの本質は「こういう状況と入力から、こういう振る舞いと出力を期待する」というレベルまで要約できる。そして、これらは1行でまとめられることが多い

• テストの入力値は、コードを完全にテストする最も単純な組み合わせを選択する

おわりに

ここまで読んでいただきありがとうございます。 

本書の中では、イラスト・実際のコードを使って解説しており、とても分かりやすくて読んでいて楽しい本だったのでオススメです。 

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

早いもので、もう4月ですね。

次は何を読もうかなー。

来週も頑張ります！