ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】リーダブルコードを読んで、一流のプログラマーに憧れて

読書感想文です。

 

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

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

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)
  • 購入: 68人 クリック: 1,802回
  • この商品を含むブログ (140件) を見る
 

 

この本を読もうと思った理由

 

良いコードを書こう系の情報を集めていると自然に目に入ってくるほど、色々な所で評価されている本だからです。

 

私は普段SIerでサーバ屋さんやセキュリティ屋さんの顔をして仕事しているので、ぶっちゃけ仕事に直結する本ではないです。ただぼんやりと未来の事を想像すると、私が現役で働いている間にサーバ屋の仕事ってどんどん減っていくだろうなと思っているので、これからも技術者として生きていくならキチンとコードを読み書きできるスキルが必要になる。

 

特に書くってところはある程度の数をこなさないとダメで、しかも漫然と数をこなしてもこれまたダメで、武道の型のように清く正しく美しい基本を身に着けた上で書かないといけないと考えています。これまで三十余年生きてきて勉強もスポーツも仕事も大抵の事はそうでした。たぶんプログラミングも同じだと思います。

 

というわけで、清く正しく美しい型を求めて本書を手に取ってみたということになります。

 

インターネッツ上で「英語版PDFは公開されてる」という情報を見たので検索してみました。本家ではなくアーカイブサイトですけど、メモとして残しておく。

https://the-eye.eu/public/Books/IT%20Various/the_art_of_readable_code.pdf

(リンク切れでした)

 

論文検索系のサイトです。

[PDF] The Art of Readable Code | Semantic Scholar

 

 

全体の感想

読みやすい本

まず1つ目に書きたいことは、とても読みやすい本だったということ。

本書はオライリージャパンの出版ですが、とても読みやすかったです。オライリーは全般的に ”良い意味で” 堅いところがある印象ですが、読み物系やマジ初心者向け系は割と読みやすい本が多いです。この本も読み物系としてかなり読みやすいです。

「良い本とは聞くけど、ボク ”No オライリー” なんですよ」という方でも余裕で読めます。私はオライリーチャレンジに失敗して何冊か本棚のオブジェとしてしまいましたが、これは楽勝で読めました。

 

訳者まえがきに書いてあるんですが、「(コードの)読みやすさを扱った本の翻訳が読みにくいというのではシャレにならない」 とある通り、訳者がいい仕事をしてくれています。もちろん原著が素晴らしいのはそうなんだと思いますが翻訳のせいでダメになる本もいっぱいある中で、本書が読みやすいのは訳者の仕事のおかげなんだろうと読後に思いました。

内容自体もシンプルで読みやすいです。全体ボリュームは200ページ程度だし、1つの章は10ページくらい、1つの節は1~2ページです。ちょっとした空き時間や休憩時間にパラパラ眺めるのにいい感じです。

 

本書にはコードを綺麗にするために、「明確な単語を選ぶ」とか「大きな問題を分割する」などなどのテクニックが紹介されています。本書で紹介されている「読みやすい良いコードを書くテクニック」は本書の執筆にあたっても同じく使われているんだろうなと感じました。全体的に読みやすい良い設計がなされている本という印象です。

 

読み手を選ぶかもね

全体通しての2つ目の感想は、「読み手を選ぶかも」です。この本はサブタイトル「より良いコードを書くためのシンプルで実践的なテクニック」の通り、シンプルなテクニックについて書いてあります。

本書はそれなりにコードを書けるけど、効率性や美しさを追及する上級者には至らない中級者層をメインターゲットにしているんだと思います。上級者から見ると「新しいことは何も書いてなかった。自分にとって当たり前の内容ですけど。ははん。」と映る内容です(たぶん)。逆にプログラミング初心者には「CとかJSとかPythonとかいろんなプログラム言語でサンプルが書いてあるので無理。あたしRubyしか分からないし。」と思うでしょう。

基本的には何らかの言語で”アプリケーション”と呼べる代物を作ったことがあって、作れるけど綺麗でエレガントなコードを書きたいと思っている人が対象になるかと思います。

 

と思ったんですが踏み込んで考えるとちょっと違うかも。

読み手側の反応を考えると上に書いたように上級者は「ははん」だし、初級者は「むり」という反応を示すと思います。ただ書き手側の思いはまた別物だろうなと思います。上級者には知識の整理に使って欲しいし、知らないことがあったらコードの書き方をアップデートしていってもらいたい。初級者にはそれこそ早く知ってもらいたい内容という思いがあるのだと推察いたします。

 

というわけで結局プログラム書く人はレベルに依らず皆読んだ方がいい本ってことになる。うんたぶんそうだ。

 

内容が良い

3つ目は内容が良いって話です。プログラミングの基本的なお作法が纏められているので私のように独学でアプリケーション作っている人間にはとても有難い書籍でした。

一例を挙げると、変数のネーミングのところは特に刺さりました。tmpとかretvalという名前の変数を作ることがよろしくないというのは、一般論として聞いたことがあったし、実践して苦い思いもしたので理解していました。ただし本書によると、本当にその変数の役割が一時的なものである場合はtmpでいいと記載されていました。このようにtmpが本当にtmpであるならOKといった具合に名が体を表すことこそが重要だと。しかし何でも拘ればいいってもんでもなくて、スコープが狭い数行の中でしか生きられない変数であれば頭文字一文字でもOKだと書いてある。

「名前に拘ろう、tmpは良くない」というのは感覚的に理解できていたが、なぜだめなのか、どうしたらいいのか、一切合切ぜんぶダメなのか、と問われると本書を読む前だったら論理的に説明できなかったと思う。こういった内容が頭の中で整理できて、なぜダメなのかが理解できると応用を利かすことができるようになる(気がする)。

 

別の方のブログエントリで、「読みやすさと言っているけど、定量的な評価がなされていない」という意見も見かけました。確かにそうだなと思いました。こういった海外翻訳本だと綿密な調査をベースにしてこっちの方が良いとか悪いとかってことを論じる本が割にあるイメージですが、本書ではそこまでやった上で書かれているわけではありません。これについては本書内でも「最終的には個人の好みになってしまうこともある」と書かれているので、そういうことなんでしょう。本書では「一貫性のあるスタイルは、正しいスタイルよりも大切だ」ともあります。一貫して汚いコードではだめだけど、どっちの書き方でも一長一短あるよねということであれば、どちらが優れているかよりもその書き方で統一されているかのほうが大事であると。

 

メモっておきたいところ

個人的にクリップしておきたいと思ったところを簡単にまとめます。

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

明確な単語を選ぶ

名前を付けるとき「取ってくる系だからとりあえずGET」と考えるのではなく、ネット経由ならDownloadにするとか、動作や状態を説明するよりよい単語を使う。

 

tmpやretvalなどの汎用的な名前を避ける

絶対禁止ではないけど、tmpが本当にテンポラリなのかちゃんと考えよう。変数の生存期間が長いと、あらためて読んだ時に「あれ?このtmpって何入ってるんだっけ?」となり読みやすいコードとは言えない。

 

スコープが小さければ短い名前でもいい

tmpの話とも似ているけど、数行程度でしか生きられない狭いスコープの中でだったら長ったらしい具体的な名前をつけなくても読みやすい。

 

3章 誤解されない名前

限界値を含めるときはminとmaxを使う

境界値を含む/含まないで発生する不具合をなくすために、min、maxという単語を使う。以上以下、未満の情報を名前に含める。

 

範囲を指定するときはfirstとlastを使う

start/stopで指定すると、stopが指すものが範囲に含まれるか曖昧になる。lastであればより明確に包含関係を表現できる。

 

ブール値の名前

ブール値の変数名は、より状態を明確にするために、is・has・can・shouldを先頭につけるのがいい。

 

4章 美しさ

一貫性と意味のある並び

一連のコードの中で、ある場所ではABCと並んでいるものは別の場所でも同じ並び順で書く。

 

個人的な好みと一貫性

最終的に個人の好みになってしまうこともあるが、「正しい」スタイルよりも「一貫性」のあるスタイルの方が大切だ。

 

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

コメントするべきでは「ない」こと

コードからすぐに読み取れる内容はコメントに書かない。

 

ひどい名前はコメントをつけずに名前を変える

名前だけでは正確に内容を読み取れないところにコメントを書くのではなく、名前自体をわかりやすいものに変える。

 

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

あいまいな代名詞を避ける

「これ」「その」などの代名詞を使用することは避ける。

 

入出力のコーナーケースに実例を使う

コメントに入出力の実例を書く時は、境界値を意識して読み手の理解を促す例を使う。

 

情報密度の高い言葉を使う

コメントは長々と正確に書くのではなく、密度の高い言葉で簡潔に書く。

 

第二部以降の覚えておきたいところ

  • 無関係の下位問題を抽出する
  • タスクを小さくして、一度に1つのことを
  • ネストを浅くする(読み手の精神的スタックにプッシュする量を減らす)

 

おわりに

こりゃ良い本ですわ。

私のように独学でコードを書いている人は、コードレビューなんて受ける機会が無いので、ダメな書き方なところがいっぱいあるんだろうなと思っていたんです。本職の人もそうかもしれないですが、自分で書いて一通り動作しているコードを修正するのを極端に面倒に思ったりもします。

 

この本の内容を生かして、未来の自分が理解しやすいコードを書いていこうという気持ちが出てきました。

プログラミング初心者の方は早い段階で綺麗な型を身に着けられるし、上級者にとっては言語化されてまとめられているものとして有用だろうしと、多くの人の役に立つ素晴らしい本だと思います。ネット上で高い評価を受けているのも納得です。

 

久しぶりに気に喰わない所の無い本でした。

 

以上