リーダブルコード

コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介する。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明する。日本語版では Ruby や groonga のコミッタとしても著名な須藤功平氏による解説を収録。

コードは理解しやすくなければならない、という一つの原則を、変数名の選び方からテストの書き方までの具体的な場面に当てはめていく本が『リーダブルコード』 (Dustin Boswell、Trevor Foucher 著、角 征典 訳、オライリー・ジャパン、2012 年 6 月刊) です。副題はより良いコードを書くためのシンプルで実践的なテクニック、原書は The Art of Readable Code で、Theory in practice シリーズの一冊として刊行されました。プログラミングの文法は一通り身につけたものの、自分のコードがレビューで読みにくいと言われる、あるいは他人のコードを読むのに時間がかかりすぎると感じている人に向けた実践書です。

名前とコメントからテストまで、4 部 15 章の構成

1 章「理解しやすいコード」で、読みやすさを「理解するまでにかかる時間」で測るという基本の考え方を示し、続く 4 部で適用範囲を少しずつ広げます。第 I 部「表面上の改善」は名前に情報を詰め込む方法、誤解されない名前、見た目の美しさ、コメントすべきことの見極め、コメントを正確で簡潔にする方法の 5 章です。第 II 部「ループとロジックの単純化」は制御フロー、巨大な式の分割、変数と読みやすさの 3 章、第 III 部「コードの再構成」は無関係の下位問題の抽出、一度に 1 つのことをする書き方、コードに思いを込めること、短いコードを書くことの 4 章です。第 IV 部「選抜テーマ」は 14 章のテストと読みやすさと、15 章の「分 / 時間カウンタ」の設計と実装の 2 章で、後者では複数の試案を比較しながらそれまでの原則を通しで適用します。巻末には付録「あわせて読みたい」と、Ruby や groonga のコミッタとして知られる須藤 功平 氏による日本語版の解説が収録されています。

小さな書き方の積み重ねが保守の費用を左右する理由

ソフトウェアの費用の多くは、書いた後に読まれ、直される段階で発生します。tmp や retval のような汎用的な名前、範囲の端を含むのか含まないのかが分からない引数名、深くネストした条件分岐は、どれも一つずつは小さな問題ですが、読み手が意図を推測する時間を毎回少しずつ奪い、誤読による不具合の原因にもなります。本書の目次には、限界値には min と max、範囲には first と last、包含 / 排他的範囲には begin と end を使うといった命名の指針や、関数から早く返す、ネストを浅くする、説明変数や要約変数で式を分割するといった手法が並び、どれもその日の実装から試せる粒度です。設計の大きな枠組みを変えなくても、名前と式と関数の切り出し方を変えるだけで読みやすさは大きく変わるという考え方は、日々の リファクタリング の判断基準としてもそのまま使えます。

前提知識と、次に読む本への橋渡し

前提として求められるのは、何らかの言語で関数や条件分岐、ループを書いた経験です。特定の言語やフレームワークの使い方を学ぶ本ではなく、どの言語でも通用する書き方の原則を扱うため、職種や言語を問わず読めます。逆に、クラスの責務の分け方やモジュール間の依存関係、アーキテクチャの選び方といった、関数より大きな単位の設計を体系的に学びたい人には範囲が足りません。そうした段階に進むときは、マーティン・ファウラーの『リファクタリング』や設計の本へと読み継ぐのが自然で、具体的な読書の順序は リーダブルコードの次に読む本 にまとめています。また、レビューで指摘する側に回る人にとっては、本書の章題がそのまま指摘の語彙として使える点も実用的で、指摘の根拠となる知識の広げ方は コードレビューが上手い人は何を読んでいるのか でも扱っています。

新人研修やチームの勉強会で書き方の共通認識を作りたい人、レビューのたびに同じ種類の指摘を繰り返している人、自分のコードを半年後の自分が読めるか不安な人にとって、本書は投じた時間がその週のコードにすぐ表れる一冊です。章題が具体的な場面ごとに区切られているので、手元のコードで困っている箇所に近い章から当てはめて試し、効果を確かめながら読み進められます。