リーダブルコードを読み返した感想

会社の人に、もう一度この章読んでみてと言われたので読み返してみました。
そしたら、いろいろと「あー、最近できてないな」と思うことがあったのでメモ

指定された章は

  • 7章 制御フローを読みやすくする
  • 8章 巨大な式を分割する
  • 9章 変数と読みやすさ

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

条件式の引数の並び順

この節はふと気を抜くと雑になりがちなので、メモ

左辺: 「調査対象」の式。変化する
右辺: 「比較対象」の式。あまり変化しない。

割りと仕事では日付のロジックをいれることがある。
販売期間内か?という判定のときは

1
2
if Date.today >= start_date ||
Date.today <= finish_date

の方が読みやすいということかな。意識してみます。

if/else ブロックの並び順

  • if 文で条件式を書く際は、優劣や単純さを意識して書くこと
    • メインとなる処理を先に持ってくる

ここは、まぁ…意識できてる…かな?

三項演算子

三項演算子は読みやすくもなるし、読みにくくもなる。
なんでも三項演算子を使えばいいというものでもない。
私自身は、割りと普段から使わないように心がけているので、逆に三項演算子使ったほうが読みやすいのに…。と言われるケースもありますw

do/while ループを避ける

do/while も割りと普段は全く使わないですね〜。
レスポンスに next_page など含まれる場合のときにレスポンスが終わるまでループさせるとか。そういったときにしか使わないので大丈夫かなと思ってます。

関数から早く返す

この節は私はちゃんと意識しないとなと思っているところですね。
ガッとコード書いてふと見たらひとつのメソッドの処理がめちゃくちゃ長くなってしまっている…。ということが割りと多いです。
多分、テストファーストでミニマムにメソッドを追加していくということができていれば自然とできるようになりそうな気はしてます。

ネスト

ついついコードを書いていったら「あー、この判定もしなくちゃ」となってネストが深くなりがちですねw
私の場合は 2 つ以上ネストが深くなってきた時点でメソッドに切り出したりとかします。
それが結局読みやすいコードになっているかは自信が無いですが…。
でもそれを意識すれば、ネストは浅くなるし、早めに返すとか、ループ内部のネストもなくなったりなど自然とできてくるのかなとか思っています。

8章 巨大な式を分割する

説明変数

これは私はよくやりますが、やりすぎて無駄な変数が多くなってしまうことも… (-_-;)
あと、説明変数のつもりでも逆にわかりにくい命名をしてしまい、意味をなさないこともあります。
語彙力ェ…

要約変数

私は条件式の中に似た記述が出た時点で変数に格納したくなるので、この例であれば大丈夫かなと思います。
条件式以外の場面で要約変数ってどこで使うのかな。

ド・モルガンの法則

この法則は忘れがちなのでメモ。
「not を分配して and/or を反転する」
逆は、
「not をくくりだす」

下記は同じ条件式

1
2
!(a || b || c)
!a && !b && !c

これもそうかな…?

1
2
3
if in_stock.blank? || (Date.today < start_date || Date.today > finish_date)
skip
end
1
2
3
unless in_stock.present? && (Date.today >= start_date && Date.today <= finish_date)
skip
end

後者の方がわかりにくいw
あと、不等式も多分反転させる気がする。

短絡評価の悪用

「頭がいいコードに気をつける」
私はあまり頭が良くないのであまり一行でいろいろやったりはしないですねw
ruby だとメソッドチェーンとか簡単にかけますが、私はあえてしなかったり。
同じチームの方でこういうコードを見かねたことがあったので、コードレビューのときにこの話を引き合いにコメントしてみるのも良いかも?

複雑なロジックと格闘し、より優雅な手法を見つける

複雑なロジックにぶつかることも多々ありますが、そこで「反対」から考える。というのがほ〜なるほどって感じでした。

巨大な文を分割する

どこから巨大なのだろうとは思いますが、割りと 3 つ以上条件式が並び始めたら危険な匂いを感じますねw
あと、 “highighted” のタイプミスは全く気付かなかったw

式を簡潔にするもう1つの創造的な方法

重複している処理はメソッドに切り出す…?という理解でいいのかな。
ruby は割りと DRY な原則という文化があるのでこのあたりは大丈夫かも?

9章 変数と読みやすさ

変数を削除する

この節は反省の多い節でした

  • 役に立たない変数
    • 私自身、過剰に説明変数を使いすぎてしまうところがあるので気をつけます…。
  • 中間結果を削除する
    • 私も割りと array とか hash とかの変数を作ってしまいがち…。
  • 制御フロー変数を削除する
    • while 文自体使わないので、割りと大丈夫…かな?
    • あと、 boolean だけ格納する変数もあまり作らないですね〜

スコープについて

  • 変数のスコープを縮める
  • C++ の if 文のスコープ
    • 条件式の中だけで使われている変数は、条件式の中で定義してしまう。というもの
  • javascript で「プライベート変数」を作る
    • 普段から変数を宣言する時は var をつける意識をします
  • ブロックスコープ
    • ブロックで定義された変数はその関数全体に「こぼれ出る」
      • これは知らなかったです
    • でも他の節の「中韓結果を削除する」といったプラクティスを活用すれば未然に防げる
  • 定義の位置を下げる
    • 私は普段は変数の定義は対象の処理の前に行うようにしているので大丈夫かなとは思ってます
    • ただまぁ気を抜くと定義と処理が離れてしまっていることもありそうなので、改めて気をつけます

変数は一度だけ書き込む

これもまぁ意識できているかなとは思います。

以上、感想になります。
普段意識できているところ、意識しないといけないと反省するところがあって、定期的に読み返してもいいのかなと思いました。