この本は
有名な著書で、簡単に要約すれば、「読みやすいコードとは分かりやすいコードなのだ」ということを記述している本でした。
全体で15章から成っており、231ページほどで構成されています。
リーダブルコードを読んで、読みやすいコードについて再度理解を深めるにはもってこいののものでしたので、おすすめします。
第1章 理解しやすいコード
理解しやすいコードというのは、以下のように述べている。
理解しやすいコードは、優れた設計やテストのしやすさにつながることが多い
「このコードは理解しやすいだろうか？」と自問自答してみることが大切だ
第2章 名前に情報を詰め込む
理解しやすいコードを書く為の鍵となる答えは、名前に情報を詰め込むことだと筆者は述べる。
明確な単語を選ぶ
名付ける名前に、明確な言葉を指定するのが望ましいとしている。
ただ、やりすぎは良くない。気取った言い方になってしまうとNGだとも言っている。
そして最後にこう締め括る。
tmpという名前は生存期間が短くて、一時的な保管が最も大切な変数だけに使おう。
抽象的な名前よりも具体的な名前を使う
誰がみても分かりやすいように、具体的な名前をつけるようにすると良いとしている。
名前の長さを決める
名前の長さはコードの行を無駄に増えてしまうことを示唆している。
そこで、識別子の「スコープ」（その名前が見えるコードの行数）が小さければ、情報を詰め込ませる必要はない為、短い名前にすると良いとしている。
頭文字と省略形
先程、名前は短ければ良いとしていたが、その省略した名前を新しいチームメイトが理解できているのか、理解出来るのかを考え直すのが良い。
理解できるなら問題ないとしている。
不要な単語を投げ捨てる
名前に含まれる単語を削除しても、情報が全く損なわれない場合も存在すると筆者は述べている。
そういった時は、不要な単語を削除しても良い。
第3章 誤解されない名前
誤解される名前には気をつけろということをこの章では述べている。
その為に、鍵となる考え方は「名前が他の意味と間違えられることはないだろうか？と何度も自問自答する」としている。
そして結論のこう結んでいる
最前の名前とは、誤解されない名前である。つまり、君のコードを読んでいる人が、君の意図を正しく理解できるということだ。
名前を決める前に反対意見を考えるなどして、誤解されない名前かどうか想像してみよう。
第4章 美しさ
優れたソースコードは「目に優しい」ものでなければいけない。
この章ではコードを読みやすくする為の余白・配置・順序について説明されている。
・読み手が慣れているパターンと一貫性のあるレイアウトを使う
・似ているコードは似ているように見せる
・関連するコードをまとめてブロックにする
整列すべきなのか？
コードを書く時、縦の線を意識して書くことで、その縦の線が「視覚的な手すり」になれば流し読みが楽にできるようになる。
これは初めに述べていた「似ているコードを似ているように見せる」の一例とも言えるらしい。
一貫性と意味のある並び
ファイルに記載するコードの並び順は、意味のある配列で記載するのが望ましいとしている。
例えば、以下のように並べることを薦めている。
・対応するHTMLフォームのフィールドと同じ並び順にする
・「最重要」なものから重要度順に並べる
・アルファベット順に並べる
コードを「段落」に分割する
文章は複数の段落で分割されている。そこで、コードも同様に段落で分割すると良いとしている。
その理由を以下のように挙げている。
・似ている考えをグループにまとめて、他の考えと分ける為
・視覚的な「踏石」を提供できるから。これがなければ、ページの中で自分の場所を見失ってしまう
・段落単位で移動できるようになるから
上記のような理由から、段落ごとにコードを分割することを薦めている。
第5章 コメントすべきことを知る
本章では、コメントすべきことを知ることにある。
その為にはまず、コメントの目的を知る必要がある。筆者は以下のように述べていた。
コメントの目的は、書き手の意図を読み手に知らせることである。
コメントすべきでは「ない」こと
コメントを書く時に、意識するべきことは、何に対してコメントを記載するのか考えることだと言う。
そしてコメントすべきではないことは以下のように述べる。
コードからすぐわかることをコメントに書かない。
コメントのためのコメントをしない
ひどい名前はコメントをつけずに名前を変える
あるコードがあって、名前がひどく読みづらいが、コメントは優れているものがあった。
プログラマの間では以下のように呼ばれている
優れたコード > ひどいコード + 優れたコメント
補助的な役割を持っていたはずのコメントがどんなに優れていたとしても、優れたコードにはならない。
名前に誤りがないか、コメントだけ優れていることはないのか、今一度確認する必要がある。
自分の考えを記録する
コメントは自分の考えを記録する役割も担っていると筆者は述べる。
コードの欠陥にコメントをつける
コードは絶えず進化しているので、その過程で欠陥を生む運命にある。
その欠陥を文書化することを恥ずかしがるのではなく、記載するようにするのが望ましいとしている。
例えば、以下のようなコメント例が挙げられている。
| 記法 | 典型的な意味 |
|---|---|
| TODO: | あとで手をつける |
| maybe-later | あとで直す |
| FIXME: | 既知の不具合があるコード |
| HACK: | あまり綺麗じゃない解決法 |
| XXX: | 危険！大きな問題がある |
上記のようなコメントの付け方を実施することで、コードの品質や状況を伝えたり、さらには改善の方向を示したりすることができるとしている。
定数にコメントをつける
定数の値を決めた時に、頭の中で考えていたことを記録することが大切だと述べている。
読み手の立場になって考える
「他の人」つまり「プロジェクトのことをあなたのように熟知していない人」が、どのように見えるのか想像することが必要だ。
また、コメントの位置はそのコードを使う「前」に記載して告知するのが望ましいとしている。
ライターズブロックを乗り換える
コメントを書くのは敷居が高いことではない。書く作業は3つの単純な手順で分解することができるとしている。
・頭の中にあるコメントをとにかく書き出す
・コメントを読んで（どちらかと言えば）改善が必要なものを見つける
・改善する
上記の作業を実施することで、コメントをつけることを早めに実施することが可能になり、結果として最後にまとめて大量のコメントを書くような事態に陥ることはないと述べていた。
第6章 コメントは正確で簡潔に
コメントを書く時には、正確且つ簡潔に記載するようにしようとざっくり書かれている。
要点としては、
・複数のものを指す可能性がある「それ」「これ」などの代名詞を避ける
・関数の動作はできるだけ正確に説明する
・コメントに含める入出力の実例を慎重に選ぶ
・コードの意図は詳細レベルではなく、高レベルで記述する
・多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
としている。
第7章 制御フローを読みやすくする
条件やループなどの制御フローがないコードは読みやすい。
コードを読む時に他のところへ飛んでいくのは読みづらくなるので、分かりやすくするための工夫を本章では記載していた。
筆者は制御フローについて以下のように述べている。
条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く
また、コードを変更する際の注意を以下のようにしている。
変更する時にはコードを新鮮な目で見る。一歩下がって全体を見る。
第8章 巨大な式を分解する
人間は一度に3~4の「もの」しか考えられない。
そこで、巨大な式は飲み込みやすい大きさに分割することが望ましいとしている。
説明変数
式を簡単に分割するには、式を表す変数を使えば良い。
この変数のことを「説明変数」と呼ぶらしい。
要約変数
式を説明する必要がない場合でも、式を変数に代入しておくと便利になる。
大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする変数のことを「要約変数」と呼ぶらしい。
著者はブール演算子は短絡評価を行うものが多いと述べていた。
「頭がいい」コードに気を付ける。あとで他の人がコードを読む時にわかりにくくなる。
まとめとして、説明変数を導入するメリットについて以下のようにしている。
・巨大な式を分割できる
・簡単な名前で式を説明することで、コードを文書化できる
・コードの主要な「概念」を読み手が認識しやすくなる
第9章 変数と読みやすさ
前章では変数の利用について触れていたが、本章では変数を適当に扱うと、理解しにくくなることについて明記している。
そして変数を記載する時、その変数のスコープを縮めることを薦めている。
変数のことが見えるコード行数をできるだけ減らす
上記のように、見えるコード行を減らすには理由があった。
それは、一度に考えなければならない変数を減らせるからだ、としている。
変数の変更はできるだけ少なくするのが良いと筆者は述べている
変数を操作する場所が増えると、現在値の判断が難しくなる
第10章 無関係の下位問題を抽出する
エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。としている。
本章では、無関係の下位問題を積極的に見つけて抽出することである。
やり方としては以下を示している。
①関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する
②コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは無関係の下位問題を解決しているのか？」と自問する
③無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする
やり方③の関数にまとめることは、やりすぎても良くないとしている。
コードを再利用する為にも、プロジェクト固有のコードから汎用コードを分離すると良いだろう。
第11章 一度に一つのことを
一度の複数のことを実行するものは理解しにくい。それと同様に、コードは1つずつタスクを行うようにしなければならないと述べている。
第12章 コードに思いを込める
冒頭にアインシュタインの文が引用されている。
おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない
誰かに複雑な考えを伝える時に、細かいことまで話すぎると相手を混乱させることになると筆者は述べている。
そして、こうも言っている。
自分よりも知識が少ない人が理解できるような「簡単な言葉」で説明する能力が大切だ
このように、コードをより相手に伝える言葉で書く為の簡単な手段を以下に記している。
- コードの動作を簡単な言葉で同僚にもわかるように説明する
- その説明の中で使っているキーワードやフレーズに注目する
- その説明に合わせてコードを書く
第13章 短いコードを書く
最良のコードは何も書いていないことである。としている。
その上で、できるだけ新しいコードを書かないようにする為には、以下のことを考える必要がある。
・不必要な機能をプロダクトから削除する
・最も簡単に問題を解決できるような要求を考える
・定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく
第14章 テストと読みやすさ
テストを読みやすくすることは、保守しやすいものにすることである。
この章で鍵となる考え方は以下の考え方で、これを意識することによりテストコードが改善されるとしている。
他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
最後にまとめとしてテストを改善する点が述べられている。
・テストのトップレベルはできるだけ簡潔にする。
・テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する
・テストに有効な最も単純な入力値を使う
・テスト関数に説明的な名前をつけて、何をテストしているのかを明らかにする
第15章 「分/時間カウンタ」を設計・実装する
様々な解決策を用いて実際に設計・実装を示す章だった。
まとめ
それぞれの章ごとにコードの実例とそれに伴う説明文が細かく記されているので、おすすめします。
今回はコード部分は大幅に割愛して語句のみを抽出しました。
詳細を学ぶには、実際に購入された方がわかりやすいかと思うので、購入してみてください。
最後までお読みいただきありがとうございました。