全てのエンジニアにお勧めしたい本。それが「リーダブルコード」です。
読みやすく、理解しやすいコードを書くための方法がまとめられた本です。 本名の通り「Readable（読める） Code」ということですね！！
リーダブルコードが訴えていること
コードは理解しやすくなければいけない
この考えがこの本の中心となります。この考えを達成するための考え方、方法を様々な角度から述べています。
「読みやすいコード、理解しやすいコード」を書く。そのための技術がこの本にギッシリと詰まっています。
本ブログでは日々の業務でコードを記述している若手エンジニアに明日から即効果がある部分を抽出して解説していきたいと思います。
では、まず最初に「理解しやすいコード」が持つ価値からはじめましょう！
理解しやすいコードの価値
「理解しやすいコードを書いた方が良い」と言われると、「はい。そうですね」としか答えられないわけですが、とは言っても仕事としてコードを書いている以上、動くコードを書かないと仕事が完了できません。
だとしても、理解しやすいコードを書くために労力を割くことには価値があります。なぜなら、理解しやすいコードを書くことで「品質」だけでなく、「生産性」も向上するからです。
品質だけじゃない！生産性も向上する！
エンジニアの仕事では、実はコードを書く以上にコードを読むことに時間を消費します。
目の前のコードが何をしているのか？を把握しないことには書くコードを決めることができません。 そのため、「理解しやすいコード」を書くことで「コードを読む」時間が圧縮されて「生産性」が向上します。
コードを書く時間と読む時間の割合は状況によって変わりますが
「書く：読む」が「10%～40%：90%～60%」
と言う感じでコードを書く担当の人でも、コードを読む時間の方が多くなります。
コードを読む時間が減れば生産性が上がる
プロジェクトに参加する人数が多いほど、上流に近いエンジニアほど、コードを読む時間の割合が増えます。
プロジェクトに参加する人数が多いと、自分以外の書いたコードが沢山出来上がります。そのため、コードを読む時間が増えます。ここで理解しやすいコードを書くことができれば、全員のコードを読む時間が圧縮できるため生産性向上に効いてきます。
上流に近いエンジニアは設計を考えるためにコードを読む時間が増えます。上流のエンジニアは給料（いわゆる単価）も高くなりますので、コードを読む時間が圧縮できるとこれまた生産性向上に効いてきます。
品質は生産性にどの程度影響するのか
理解しやすいコードを書くことを心がけることでコードの品質が高くなります。
理解しやすいコードが品質と生産性を同時に向上することは前述の通りです。しかし、品質が生産性に及ぼす影響がどれ位あるのか？は説明が難しいです。
これに対して、2022年の研究で品質がビジネスに与える影響を「時間」という数字で計測した論文が発表されました。
この論文を非常にざっくりまとめると以下になります。
- コードの品質をコード分析ツール「CodeScene」で計測する
- 「最も低品質と判断されたコード」と「最も高品質と判断されたコード」を比較
- 悪いコードは、良いコードに対して15倍のバグ発生数
- 悪いコードは、良いコードに対して開発時間が「平均2倍」、「最大9倍」
つまり、同じ機能を同じ時間で書ける人がいたとすると、理解しやすいコードを書ける人は、理解しやすいコードが書けない人よりも平均で2倍、最大で9倍も生産性が高いと言えるわけですね。
単純に開発時間でも2倍～9倍の生産性となるのに、その後のバク発生数が15倍違うとなると、コード品質の重要性が良く分かりますね！
内容紹介
1章 理解しやすいコード
- 1章 理解しやすいコード
- 1.1 「優れた」コードって何？
- 1.2 読みやすさの基本定理
- 1.3 小さなことは絶対にいいこと？
- 1.4 「理解するまでにかかる時間」は競合する？
- 1.5 でもやるんだよ
1章では、本書の中心となっている「理解しやすいコード」とは一体どのようなものなのか？を解説しています。
先に結論を言うと「読んで理解するまでにかかる時間が短いコード」を「理解しやすいコード」と定義しています。
ここで言う「理解する」とは、そのコードを読んで理解した人が「変更を加えることができる」、「バグを見つけることができる」という意味です。
コードを読んでいると「何をしているか？は分かるんだけど、何でしているのか？が分からない」ということがままありますが、これは「理解できない」ということですね。
コードの小ささと理解しやすさはイコールじゃない
本章では「理解しやすい」が「コードを小さくする」と同義になりやすいことに対しての注意喚起もしています。
コードを小さくすることが目的ではなく、「読んで理解するまでにかかる時間を短くする」手段として、コードを小さくするんだよ。ということです。
そのため、読んで理解するまでにかかる時間が短くなるのであれば
- あえて行数を分けて冗長に記載する
- コメント行を追加する
のように、読むことにかかる時間が増えたとしても、理解するまでにかかる時間が減るのであれば「ヨシッ！」になります。
リーダブルコードの具体例
リーダブルコードに記載されている具体例を引用します。
行数は増えるけど理解する時間は減る
assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());
bucket = FindBucket(key); if (bucket != NULL) assert(!bucket->IsOccupied());
コメントをつけるとコードは長くなるけど理解する時間は減る
// "hash = (65599 * hash) + c" の 高速 版 hash = (hash << 6) + (hash << 16) - hash + c;
まとめ
本記事では、リーダブルコードの中心となる「理解しやすいコード」の意味や、「理解しやすいコード」がもたらす価値について解説しました。
次回からは「理解しやすいコード」を作成するためにリーダブルコードが掲げる具体的な手法の解説をしていきます。
