リーダブルコードを読みました

翻訳者である角征典さんの このツイート に手を上げて献本頂いた 「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」 を読み終えました。

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

以下、長いですが、各章ごとに簡単に思ったことを書いてみます。

1章　理解しやすいコード

そもそも「良い」とか「きれいな」「読みやすい」「理解しやすい」とは言うけれど、どれも主観による曖昧な評価です。この章では読みやすさの基本定理を

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

と定めています。明快ですね。

第I部　表面上の改善

2章　名前に情報を詰め込む

これはもう諸手を上げて大賛成です。特に tmp や get などの汎用的な名前を避けるという箇所は大きく頷きながら読みました。

ぼくを含め、多くの日本人は英語の語彙が貧弱なために、ついつい似たような変数名や関数名を付けがちですが、これまでより少しだけ時間を掛けて考えて、よりよい名前を付けなければいけないなと思いました。

3章　誤解されない名前

コレクションを扱う際に「範囲を指定するときは first と last を使う」や「包含／排他的範囲には begin と end を使う」というテクニックは、なるほどなあと思いました。

ブール値に is, has, can を付けるというテクニックはよく使います。分岐条件がぐっと読み易くなるのでお勧めです。

4章　美しさ

この章の内容は以下のまとめに集約されています。

一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

それから、個人的に「縦の線をまっすぐにする」には反対というスタイルを貫いています :-p

5章　コメントすべきことを知る

これも大賛成です。特に「コメントするべきでは「ない」こと」などは、読んでいて「そうだ！」と叫びそうになりました。

何をしているかはコードを読めば分かりますし、システムはコードの通りにしか動きません。設計書やコメントには何故そうしなければならないのかを書き記していかないといけませんね。

6章　コメントは正確で簡潔に

これは「言うは易く行うは難し」だと思いました。簡潔さを気にし過ぎて重要な情報が落ちるくらいなら、多少は冗長でも構わないのですべての情報を正確にコメントして欲しいと思います。

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

7章　制御フローを読みやすくする

この章は必読です。関数から早く返すガード節やネストを浅くする方法など、試行錯誤の中で次第に身に付いたテクニックが網羅的にまとめられています。

なお、個人的に三項演算子はそこまで読みにくいとは思わないので、使って良いと思います。

8章　巨大な式を分割する

この章も必読です。説明変数、要約変数という名前に膝を打ちました。

先のブール値の名前と同様に、変数名や関数名に説明的な名前を付けると、英語のように読み下せるコードになります。

一箇所からしか呼び出されない private 関数は無駄だと言われることもありますが、ある程度まとまった処理を段落的に切り出して説明的な関数名を付けるテクニックは、意識的に使っています。

9章　変数と読みやすさ

この章では「変数を削除する」という点に特に共感しました。どうにも一般的な名前しか付けようのないローカル変数の命名に悩むときがありますが、多くの場合はメソッドチェーンを使うか、ガード条件で早めに関数から処理を返してしまうことで、そのローカル変数を削除することができます。

「変数のスコープを縮める」は、言語の仕様に依るところも大きいと思います。テクニックや規約も大事ですが、言語仕様でできるだけ多くの誤りを防止できると良いと思います。

「変数は一度だけ書き込む」は、関数型言語では一般的な考え方のようですので、今後 Scala を学ぶ際には意識して取り組もうと思いました。

第III部　コードの再構成

10章　無関係の下位問題を抽出する

この章もおすすめです。コーディング初心者はコードを動作させようと一所懸命になるあまり、コーディング熟練者はより高度な実装を突き詰めるあまり、この問題にはまり込んでいくように思います。

コーディングは手段に過ぎません。実現しなければならない目的を常に最優先するよう、常に気を付けていたいものです。

11章　一度に1つのことを

この章も重要ですね。処理を手続き的に上から下に書き下してしまうと、コードが断片化され、冗長で読みづらくなってしまいます。

コードから一歩離れて、実現しなければならない目的の全体像を把握してから、問題を小さく分割してひとつずつ片付けるようにすると、自然と一度にひとつのことしか実現しないコードが書けると思います。

12章　コードに思いを込める

ややスピリチュアルなタイトルですが、内容はとてもリアルです。

これ以前の章で紹介されているテクニックを駆使すると、「言葉で説明している」ようなコードが書けるようになります。コードが英語のように読み下せるのであれば、コードの内容を説明するコメントはもちろん、コードとの整合性を保つのがとても難しい冗長なドキュメントを書く必要もありません。

13章　短いコードを書く

この本は「リーダブルコード」ですので、可読性を犠牲にしてでもコードを短くせよ、という内容ではありません。書く必要の無いコードを書いてはならないという内容で、YAGNI (You Ain’t Gonna Need It) や 車輪の再発明 として知られる問題に触れています。

この本では触れられていませんが、システムを利用するユーザから実際に使用する機会のほとんど無い機能を求められることも多くあります。コードは書けば書くだけコストが掛かり品質が下がるので、必要最低限のコードのみを優先度順に確実に書かなければなりません。

第IV部　選抜テーマ

14章　テストと読みやすさ

読みやすく保守しやすいテストの書き方について網羅的に触れられています。コードは書いて終わりではなく、動いてからが本番です。コードを書いている途中は、テストコードを書くことを煩わしく感じるかもしれませんが、動き始めたコードが正しく動き続けることを保証するために、テストコードはとても有効です。

テストコードが読みづらく保守しづらいと、あっという間に負の遺産となってしまい、誰も見向きもしなくなってしまいます。この章の内容を常に念頭においてテストコードを書かなければいけないと強く思いました。

15章　「分／時間カウンタ」を設計・実装する

これまでの章の内容を使ってテストコードをリファクタリングしていく内容です。数学的なパフォーマンスの話題なので、取っ付きづらいと感じる方もいるかもしれません。

なにか新しいテクニックが紹介されているわけではありませんので、時間のあるときにゆっくりと目を通すとよいと思います。

解説（須藤 功平）

実に 9 ページに渡る熱い解説です。一部、文言を変更した全文が リーダブルコードの解説 - ククログ(2012-06-11) にて公開されていますので、興味のある方はご覧になるとよいと思います。須藤さんの熱い想いが伝わってくると思います。

さいごに

冒頭の訳者まえがきにあるとおり、この本を読んで「Nothing New (別に普通じゃん)」と思う人もいるかもしれませんが、その人はその「普通」がどれだけ普通でないか、近い将来に思い知らされることになると思います。少なくとも、ぼくの周りにはまだまだ「リーダブル」ではないコードが溢れています。

当然、この本を読んで目からウロコが落ちたように感激する人も勿論たくさんいることと思いますし、この本を読んで「これだ！」と膝を打つ人もたくさんいることだろうと思います。そういう意味で、この本は「コード」を「読む」必要のあるすべての人にとって価値のある本です。

角さん、このようなすばらしい本をお送り頂き、本当にありがとうございました。また、「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」 をはじめ、角さんの訳書には度々お世話になっており、これら海外の良著を母国語で読めることにいつも感謝しております。この場を借りて御礼申し上げます。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

参考

• 『リーダブルコード － 忘れてもいいコードを書こう。』に参加してきた #devlove - Shinya’s Daily Report