リーダブルコードを読んで腹落ちした内容を確認する。

はじめに

リーダブルコードを読んで、納得感を持って理解できた部分をメモしていく。エンジニア初学者の自分が理解できたことと、数ヶ月後・数年後の自分が理解できることは違うと思うので、時々読み返したら新たに追記していこうと思う。

履歴

2023/2/18 初読

1章 理解しやすいコード

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

他の人が自分が書いたコードを読んで理解し、修正・機能追加できるようになるまでの時間が少ないほど良い、ということである。
これまでなんとなく、わかりやすいコードにしないといけないと思っていたが、わかりやすいコードの定義というのは明確に考えていなかった。より早く理解できるようにするためにどうすべきかを考えていきたい。

第I部　表面上の改善

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

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

定義されてから役割を終えるまでの範囲が狭い変数などには、名前にそれほど情報を詰め込まなくてよい。過去のコーディングの中で、明らかにすぐ役割を終える変数に、長ったらしい名前をつけた記憶があった。丁寧に名前をつけても理解するまでの時間に影響がないなら、短い方が良いなと納得できる。

不要な単語を投げ捨てる

なくなっても情報量に影響がない単語はなくしてしまおう、ということ。変数やメソッドの名前が長くなりがちな自分にとっては、考えなくてはいけないことだと思った。名前が長くなったら、とりあえず何個か単語を抜いて並べてみよう。

4章　美しさ

一貫性のある簡潔な改行位置

一貫性のあるコードには、適切な改行を行なって一貫性のあるコードにする。これについては読む前から実践できていた。ただ、綺麗に整列されたのに満足してコードが長くなることを許容してはいけないので注意する。

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

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

コードに書いてあることの抽出でしかないコメントには価値がない。自分のこれまでの学習を振り返ると価値のないコメントをたくさんしてきた。このコメントにより、情報が増えたかどうかを逐一確認する。

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

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

コメントに限らず読み物すべてに通じるところがあるが、代名詞を不用意に使うと誤解やわかりづらさにつながる。不用意に使用した代名詞が原因で、作成したドキュメントに対して指摘を受けた記憶があったので注意したい。代名詞は名詞に変換を徹底する。どうしても使わないといけない場面もあまりないだろう。

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

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

if/elseブロックの並び順

これまで基本的にif/elseは肯定形の条件を使うべきだと感じていたが、一概にそうではないそうだ。以下二つのことを考慮に入れて、否定形から始めるif/elseも検討する。

単純な条件を先に書く

if/elseが同じ画面に表示されやすいので条件を忘れない

関心を引く条件や目立つ条件を先に書く

目立つ条件とそれ以外の構図にすることで理解しやすくなる。

if/elseでロジックを書いたら、一度は入れ替えてみてこの2つの条件を検討するようにしよう。

ネストを浅くする

自分が書いている時には複雑な条件をすべて理解しているため、ネストの深くまで行っても何をやりたいかがわかるけど、それは自分だけである。読み手の時は深いネストにとても苦痛を感じるのに、書き手になると全く注意できていないと思った。対策の一つとして、失敗ケースを早めに返して、ネストを浅くするよう意識してみる。

9章　変数と読みやすさ

変数のスコープを縮める

変数が見えるコード行をできるだけ減らすことが重要である。現職（もうすぐ前職になるけど）で扱っているCOBOLは、変数はすべてロジックと別箇所で定義しないといけなかったのでとても納得した。既存のロジックを追う時に、毎度毎度変数の定義を確認しにいくのはとても苦痛である。（可能であれば）変数の定義は変数を使う直前に行い、それが使用される範囲は可能な限り狭くすることが重要である。

第Ⅲ部　コードの再構成

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

ロジックを明確に説明する

自分が書いたロジックを簡単な言葉で説明してみることで、複雑になったロジックを自然な形に単純化できるかもしれない。逆に、簡単な言葉で説明しきれない場合は、書こうとしているロジックのタスクが細分化されていない可能性が高い。相手を想像してロジックについて説明してみたうえで、自分が発した言葉を整理し、ロジックに落とし込む。

13章　短いコードを書く

その機能の実装について悩まないでーきっと必要ないからプロジェクトに欠かせない機能を多く見積もってしまうのをやめようという話。不要なコードはない方がまし、ということである。この話題と完全に一致しているわけではないが、現職で似たようなケースに遭遇した。本番環境で動いているプログラムのテスト用プログラムに不要なバリデーション機能があったという話である。その不要なバリデーション機能のせいで、テスト用プログラムのために新しくインプットを一つ用意しなければならず、しかもそのインプットをストックして保守していた。（しかも実はバリデーション機能自体もロジックが誤っていて正常に動いていなかった。）

身近なライブラリに親しむ

既存のライブラリで解決できることは、ライブラリで解決しようという話。がんばって書いたコードがこの関数を使えば一発で書けていた、というのは自分も経験がある。「たまには標準ライブラリのすべての関数・モジュール・型の名前を１５分かけて読んでみよう。」という言葉に、とても納得した。

第Ⅳ部　選抜テーマ

14章　テストと読みやすさ

最小のテストを作る

テストコードが何をしようとしているかは基本的に１行で書くことができる。こういう入力を与えると、こういう出力が返ってくる。
当たり前のことだが、言われると納得した。結論ファーストで話すこととなんら変わらない。

おわりに

最初に記述した通り、何度か読み返して腹落ちした部分を増やしていこうと思う。履歴のところが増えていって、いずれ本書の全文章がこの記事に書かれてるといいな。