書評『リーダブルコード』

October 11, 2020 | 4 min read | 370 views

はじめに

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Dustin Boswell，Trevor Foucher 著，角征典訳，オライリージャパン，2012年）を読んだので，まとめと感想を書きます．あまりにも有名な書籍のため普通の書評を書いても百番煎じくらいになりそうですが，備忘録も兼ねて書きます．

原題は『The Art of Readable Code: Simple and Practical Techniques for Writing Better』で，サブタイトルにある通り「読みやすいコードを書くために心がけるべきこと」を説いた本です．出版が2012年と技術書にしては古めですが，「新人エンジニアが読むべき技術書」として必ずと言っていいほど挙げられる「殿堂入りの技術書」でもあります．

本書を読んで，読みやすいコードを書くのはそのコードを読む「他の誰か」だけではなく，後でそのコードを読み返す「自分」やバグのないコードを書きたい「自分」にとっても極めて重要だと改めて感じました．

「リーダブルコード」というタイトルらしく読みやすい言葉で必要十分な内容を扱っているため，数時間から数日で読めると思います．気になっているけどまだ読んでいないという方は，これを機にサクッと読んでみてはいかがでしょうか．

まとめ+α

本書は全15章からなりますが，各パートごとに私が重要だと思ったことを適宜列挙する形でまとめます．

第I部表面上の改善

第I部は主に変数・関数の命名とコメントにおいて気をつけるべきことを書いています．

名前に情報を詰め込む
- 例えば二分木のSize()メソッドなら，Height()，NumNodes()，MemoryBytes()などの名前のほうが明確である
- サーバがポートをリッスンできるか確認するメソッドなら，ServerCanStart()よりもCanListenOnPort()の方が明確である
- ある程度のスコープを持つ変数には，tmpのような汎用的な名前ではなくsum_squaresのように意味のある名前をつける
- スコープが小さい場合や慣習的な理由がある場合には短い名前を付けても良い
- 例えばfilter()という関数は，条件に当てはまるものを「除外する」のか「選択する」のかが曖昧である．exclude()やselect()といった名前のほうが誤解を生みづらい
- リストの要素数を返すsize()という名前のメソッドは計算量が $\mathcal{O}(1)$ であることを期待させる．もし計算量が $\mathcal{O}(n)$ ならcountSize()のような名前にすべきである
正確かつ簡潔なコメントを書く
- コードからすぐに分かることをコメントに書くべきではない．例えば，Node* FindNodeInSubtrree(Node* subtree, string name, int depth)という関数に与えられたsubtreeに含まれるnameとdepthに合致したNodeを見つけるというコメントを書くのは無駄である．コメントを書くなら，もしdepth <= 0ならば，'subtree'だけを調べるのような詳しい挙動を説明するべきである．もしコードから関数の概要がわからないなら，名前の方を再考したほうが良い
- ハッシュテーブルよりもバイナリツリーのほうが速かったのような試行錯誤の結果や，TODO: アルゴリズムの高速化のような欠陥に対するコメントを書くのも良い
- コードを書いた意図をコメントするのも良い．例えば，listを逆順にイテレートするではなく値段の高い順に表示するのような高レベルのコメントには価値がある

第II部ループとロジックの単純化

第II部は，コードのより内部に注目して，制御フローや変数のスコープといった観点から気をつけるべきことを扱います．

if文の条件には否定形よりも肯定形を使う
関数からなるべく早く返す
ネストを浅くする
長い式の一部を直感的な名前を付けた中間変数で置き換える
変数のスコープを縮める
変数の変更箇所を少なくする

第III部コードの再構成

コードを書く作業が一段落したら，一歩引いて見直して，長い関数の一部を新しい関数に切り出したりする「再構成」をするでしょう．第III部はこの再構成について議論します．
第III部の最も重要なメッセージは「関数の目的と無関係の下位問題を抽出して別の関数に切り出す」です．例えば，与えられた地点から最も近い場所を見つけるための関数において，「2点間の距離を計算する」作業は「無関係の下位問題」といえます．コードの再構成では，このような下位問題を積極的に見つけて，別の関数として定義すべきです．こうして得られる関数は汎用的であるため再利用しやすく，独立しているため単体テストが書きやすいというメリットもあります．このあたりは関数型プログラミングで特に重視される思想のひとつなのかなと思っています．

第IV部選抜テーマ

第IV部は，「テストと読みやすさ」と「実践的な問題を通した全体の復習」という2つのテーマを扱っています．
テストに関する重要なメッセージは，「テストコードも本体コードと同様に読みやすいものにしなければならない」というものです．テストコードが読みづらいと本体コードの動作を理解しにくくなり，また，テストコードが追加・修正されなくなるという問題があります．
「実践的な問題」の章では「分／時間カウンタ」の設計と実装を試行錯誤しながら，本書の内容を実際の現場でどう応用するか説明しています．