【読書感想文】リーダブルコード　メモその2

本書では、

do-while文は条件が下に書いてある。
普通コードは上から下に読んでいくので、場合によってはループ内を2度読むことになる。
よってdo-while文はやめよう。

的なことが書いてある。

で、「大抵のdo-while文はwhile文に書き直せる」とも書いてある。

確かに自分の経験でも大抵のdo-whileはwhileに書き直せるけど、
それで可読性が上がるかどうかは正直疑問だなぁという感じ。

逆に、「do-whileはどうしても1回はループを通る必要がある時のみ使用」
というルールで統一する方が、
whileの条件を複数にするよりも読みやすいのではないかと思っていますが、どうなんでしょう？

元のロジックをベースに、「修正箇所が少なくなる」ような修正を重ねていくと、
いつの間にかネストがすごく深いロジックが出来上がっていることがあります。

品質担保のためにソースの修正箇所をなるべく小さくするのは良いことですが、
修正する時はその差分だけを確認すれば良くても、
後から読む人はそのソース全体を読まなくてはいけないので、

ソースの差分が読みやすい

のと、

ソース全体が読みやすい

は必ずしも同義ではないことを認識しながら、
場合によっては使い分けながらコーディングする必要があるということですね。
まぁ基本的には、「最初は差分が小さくなるように修正⇒後でリファクタリング」が良いのかと。

条件のandやorが多くなりすぎて読みにくくなった時には、
実は別の条件で簡単に代用できることが多いので、考えてみよう、とのこと。

確かにロジックというのは基本的には、
「こういう場合はこれをする。違う場合はこっちをする」のはずで、
この「こういう場合」は日本語でなら一言で説明できることがほとんど。

条件が、「AかつB、またはC」みたいになっていたとしても、
それが判定したいことは「Dかどうか」で表せるはずなので、
ソースを読みやすくするためにはこのDを探すのが大事ということですね。

制御フロー変数とは、

実際のプログラムに関係のあるデータが含まれていない、
ただif文やwhile文の条件に使うためだけの変数

のこと。
そしてこういう変数は、うまいことソースを書けば削除できる、とのこと。

確かに消せるとは思うけど、これも必ずしも消した方が読みやすいかどうかは微妙だと思います。

上記の「条件が膨らみすぎたら、別の条件で代用できないか考える（8.5）」とも少し絡みますが、
どうしても膨らんだ条件を簡単にできない場合、
「Dかどうか」という名前の変数を用意するのは可読性を上げるひとつの方法かと思います。
こういう場合は制御フロー変数を用意した方が読みやすい。

まぁ「プログラムに関係のあるデータが含まれていない」変数が、
そんなに複雑になることはあまり考えられませんが。

これはリーダブルとはあまり関係ありませんが、
JavaScriptでは"var"を付けないと変数のスコープはグローバルになるんだそうです。
javaと同じようなつもりで書くと痛い目を見るかもしれない。
備忘メモしておきます。

今回はif文やwhile文など、ソースが読みにくくなりがちな制御文まわりの書き方メインでした。
個人的には、

・後からif文を足したことでネストが深くなって読みにくくなっている
・後からandやorで条件を追加したことで条件が分かりにくくなっている

ようなソースは何度もお目にかかったことがあるので、
そこら辺を意識しながら、ロジックの流れが分かりやすい制御文を書くように心がけようと思います。

終わり。