リーダブルコード 角 征典(翻訳)

本書を読むのは2回目になる。技術系の書籍で読み返した経験は無いかと思う。それ程に本書は素晴らしい。「コードの書き方」系の書籍は今までにも5冊以上は読んだが、どれも全体的には中途半端になり、それらの書籍の優れたところを合わせても本書には劣るように感じる。

それほどに本書はすばらしい。それぞれの項目については既刊のそれらと同じような項目になるが、「なぜそうしなければならないのか」、「どのように実現するのか」がきちんと書かれており、今までもこれらの書籍を読んだ経験があるが実践できていない方には特におすすめできる。本書を読めば、それらを実行することの重要度がわかり、それらを実行することでコードや自分にどのようなメリットがあるかを知ることが出来る。そしてそれを実行することが出来るようになるだろう。

書店に行けば本当に多種多様な「コードの書き方」の本がある。だが変数や関数名の付け方、コメントのつけかた、コードのまとめ方を総合的に扱った書籍はないだろう。そして、それらについても「関数名の付け方」というタイトルではなく、「誤解されない名前」と、「名前を変えることの重要性」を先に立てるのではなく、「その名前をつける理由」から解説がされており、ひねくれをこじらせている私でも順序取りにすんなり理解が出来た。

こういうたぐいの書籍は読まれるだけで実践がされづらいと経験しているが、私自身が本書を読み、それ以後に書いたコードから本書に書かれた内容を実践していることからも、「知識」を集めるための書籍ではなく、「実践」するための書籍であることがわかるかと思う。

私のこの読書感想文があまりにわかりづらいものだったとしても、是非とも本書を手に取り実際に読んで欲しい。これは出版社からではなく私からの願い、一プログラマからの願い、一コミュニティメンバーからの願いにもなる。是非とも世界のコードをよりわかりやすいものにして行こう!!

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

どんなことよりも何よりも先に以下を読んで欲しい。

Px.
本書の目的は君のコードを良くすることだ。ぼくたちが「コード」と呼んでいるのは、君がエディタで目にするプログラムコードのことだ。本書では、プロジェクトの全体アーキテクチャやデザインパターンの話はしない。そういうのも大切だけど、プログラマが日常的に時間を費やしているのは、もっと「基本的」なことだと思う。
例えば、変数に名前をつけたり、ループの処理を書いたり、問題を関数のレベルまで分解したり。こうした活動の大部分は、既存のコードの読み書きに費やされている。

本書の魅力はこれだけを読んで貰えばわかってもらえると思う。そう信じている。世の中には「コードのデザイン」や「デザインパターン」を扱った書籍が溢れており、それらはいかにそのデザインが優れているかを書き連ねているものとなっている。だが、私達はもっと低レベルなコードを読んでいるはずだ。それらのデザインを読むにはもっと低レベルなコードが読みやすくなければならない。どのようなデザインでもコードが読みやすければ理解が出来る。どれだけ優れたデザインであっても、コードが読みづらければ台無しになる。

本書はそれらのデザインを否定なんてしていない。デザインを表現するために本書を読み、デザインをより素晴らしい物にして欲しい。変数名の付け方一つでデザインの良し悪しも決まるのだ。

変数名がintervalよりも、download_intervalの方がわかりやすいはずだ。前者であれば何のインターバルかがわからない。後者ならダウンロードのインターバルであるという事がわかる。「名は体を表す」とはよく言ったものだ。名前から内容を推測でき、名前と機能がマッチしていればそれはすんなり理解してもらえ、名前から機能を思い出すことも容易にできる。変数名(関数名)が長くなることを嫌う風潮があるが、それを正しくつけることによって「考えずに済む」ようになるのであれば、後に続く者、半年後の自分のためにそうして置かなければならない。半年後の自分が変数名を見て何をするものか理解できないのであれば、それは正しい名前とは言えないのである。
また、例に出した「download_interval」というのも誤解が生まれる名前になる。ダウンロードのインターバルという事はわかるが、その変数に代入されている時間の単位がわからない。値が10であればそれが「秒」なのか「ミリ秒」なのか。「download_interval_ms」となっていれば、その変数に入れるべき単位も自ずとわかるはずだ。変数名(関数名)は人間が内容を察するものではなく、名前が自分自身のことを訴えかけてくるべきである。

だがしかし、自分が好きなように名前をつけ続ければいい訳ではない。調和が必要だ。

P53.
ぼくたちは「間違った」スタイルを使っているプロジェクトに数多く携わってきた。でも、そこではプロジェクトの規約に従うようにした。一貫性のほうが大切なことだからだ。

場所によって命名規則に乱れがあってはならない。コードは一部だけを読むものではなく、全体を理解するものになるので、全体に合わせて命名をしなければならない。そうしなければ読み手は、私が書いたコードの命名と別の人が書いたコードの命名、両方を理解する必要が出てくる。だが、既に書かれているコードに命名を合わせれば、その命名に慣れた読み手はそのままその癖をもって読み進めてくれるのだ。
自分一人が我を張ることも読み手に負荷をかけることを忘れてはならない。

名前一つにとってもこのように多種多様な考えから命名方法について解説されている。だが本書は命名の他にもループの展開、コードの分け方、コメントの付け方まで数多くの事例をもって解説がされている。また、最終章は実践的なサンプルとして設計と実装を扱っているので、知識の確認も行えるようになっている。内容もさることながら構成も素晴らしい。

是非とも本書を手にとって欲しい。

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

Code Complete第2版〈上〉―完全なプログラミングを目指して

アジャイルサムライ−達人開発者への道−

プログラミング作法