『リーダブルコード』を他書と読み比べる（その1）

よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。

1章 理解しやすいコード

ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。

コードは理解しやすくなければいけない。

コードは他の人が最短時間で理解できるように書かなければいけない。

『C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。

チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。

『Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。

簡潔性よりも明瞭性を重視してコードを書く

簡潔ではあるのものの混乱を招くおそれのあるコードと、明瞭ではあるものの長く退屈に感じられる可能性のあるコードのどちらかを選べる状況では、洗練性には多少欠けるとしても、誤解なく明確に意図を読み取れるコードの方を使用します。（中略）自分が書いたコードが誰かに読まれる可能性があるのかを考えてみてください。そのコードの保守を比較的経験の浅いプログラマーに任せなければならない場合もあるかもしれません。その担当者がコードのロジックを理解できないとしたら、間違いが起きることは必至でしょう。複雑な構文や言語仕様を巧みに利用した小技を使えば、演算子の優先順位を知り尽くした博識ぶりを見せつけることはできるかもしれませんが、それによってコードの保守性は無残に損なわれてしまいます。「コードは常にシンプルに」が鉄則です。

『Javaプログラミングの処方箋 (Programmer’s foundations)』には、逆に読みにくいコードがもたらす弊害について書かれています。

このようなコードは非常に読みにくく、このあとにこのコードを読む人に誤解を与えます。また、一度このような「汚いコード」が入ると、その汚いコードがほかにもどんどん波及していきます。元のコードが美しければ、それを「汚す」には勇気がいりますが、もともとが汚ければ誰しもコードを綺麗に保とうとしなくなります。

『プログラマのためのサバイバルマニュアル』には次のように表現されています。

人は、複雑さの逆と言われると、単純を思い浮かべる。しかし、私たちの分野には避けられない複雑さがあるので、いつでも単純なコードが書けるとは限らない。複雑さの反対語としてより適切なのは、明快である。あなたのコードがしていることは、読者にとって明解だろうか。

『プログラマのためのサバイバルマニュアル』は上記文章のあとで「2つの明快」について説明が続くのですが、「避けられない複雑さ」というのが気になります。『Developer's Code 本物のプログラマがしていること』（電子書籍もあるよ！）第4章「複雑さ」に面白いことが書かれています。

ほとんどのアイデアーーー見た目にはシンプルなアイデアーーーはその詳細に立ち入るとひどく複雑なものになる。高いレベルで考えている限り、アイデアはいつもシンプルだ。（中略）詳細に分け入ってみれば、ロジックのどこに穴があるのか、そのすべての場所が見えてくる。詳細とはそういうものなんだ。最後まで考え抜かれていないアイデア（つまりほとんどのアイデア）はこの時点で、複雑であることから逃れられなくなる。（中略）僕らは不十分であることを恐れている。そこにその答えがある。何かをシンプルに構築すると、それが十分なもののような気がしないんだ。

『Developer's Code』ではこのあと、複雑さを「コードが書くのが難しい」ことと複雑さがユーザに転移してしまった「使うのがむずかしい」ことの2つを引き起こし、「複雑さを表に出さない」こと、コードの複雑さを嫌うあまり「リファクタリングをあまりに早い段階で行うことの危険性」についての議論になっていきます。

コーディングの際にバイブル的な本として有名な『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』を参照してみると、5.2.1「ソフトウェアの鉄則: 複雑さへの対応」に、Fred Brooksの定義を引用していますね。

Brooksによれば、ソフトウェア開発を難しくするのは、本質的な(essential)問題と偶発的な(accidental)問題という、2種類の問題であるという。

どうやら、複雑さへの対応として読みやすさが重要であるようですね。また、『CODE COMPLETE』5.2.2「設計に望ましい特性」に設計の内部特性を10個挙げています。

• 最小限の複雑さ
• 保守性
• 粗結合
• 拡張性
• 再利用性
• 高いファンイン
• 低いファンアウト
• 移植性
• 無駄のなさ
• 階層化

このうち、保守性がリーダビリティに関係あります。

保守の容易さとは、保守プログラマのために設計することである。保守プログラマがあなたの書いているコードについてどのような質問をするか常に想像しよう。保守プログラマを顧客と見なし、見ればすぐわかるようなシステムを設計しよう。

Kent Beckは『実装パターン』で次のように述べています。

何をシンプルとするかは人それぞれだ。ツールと技術を知り尽くしたプログラマから見たシンプルは、初心者には複雑すぎるかもしれない。相手を意識したときに、よい文章が生まれるように、よいプログラムも読み手を意識したときに生まれる。読み手の少し上を行くのはよいが、あまり複雑すぎると、相手にされなくなってしまう。（中略）コミュニケーションとシンプルは一体となって働くことが多い。余分な複雑性が減少すると、システムの理解が容易になる。コミュニケーションを重視すれば、どの複雑性を捨てるべきかが明確になる。

コミュニケーションまで含めているのがKent Beckらしいですね。相手あっての読みやすさということでしょうか。読みやすさが重要ということが十分に意識できたので、明日は2章「名前に情報を詰め込む」に入りたいと思います。

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