最近追加されたrubocop規則を確認してみる👮♀️🚨
みんな大好きrubocop
みなさんrubocop👮♀️🚨は好きですか?
新しい書き方や効率的な書き方が発見できるし
チームでコーディングスタイルを統一でき、レビューがストレスにならないので僕は良いgemだなと思っています
そんなrubocopですが日々アップデートされ新しい規則が増えています
リリースノートはこちら
最近新しいプロジェクトで最新版のrubocopを入れて実行してみたのですが
Waringがたくさん表示されてびっくりしました
本日は新しいルールで怒られてしまった物を紹介しようと思います
versionを0.92から1.23にして怒られていたもの
Style::HashConversion (from 1.12.0)
# bad
Hash[ary]
# good
ary.to_h
# bad
Hash[key1, value1, key2, value2]
# good
{key1 => value1, key2 => value2}
これはHashの特異メソッドである[ ]を使うのではなく
Objectクラスのインスタンスメソッドであるto_hやHash.newを使ってくださいねと言ってるようです
Correction code from splat argument (Hash[*ary]) is not simply determined
理由としては引数に可変長引数[*arg]を使用した際のruby内部の変換が複雑とのことです
Lint/AmbiguousOperatorPrecedence (from 1.21)
# bad
a + b * c
a || b && c
a ** b + c
# good (different precedence)
a + (b * c)
a || (b && c)
(a ** b) + c
# good (same precedence)
a + b + c
a * b / c % d
Precedenceとは日本語で優先順位のことです
算数では*, ÷は+, -より優先されますよね
計算では問題ないけど、可読性のためにカッコをつけてくださいということだと思います
計算ならそこまで問題ではないですが、今回は以下のようなコードで怒られました
if (cat? || dog? || other_animal? && animal_detail)
この条件式は猫か犬か他の動物かつ詳細が記載されているが真ですが
最後の条件だけ複合のため、若干可読性にかけるかなと確かに思いました
Style/StringChars (from 1.12)
# bad
string.split(//)
string.split('')
# good
string.chars
これは以前のrubyのversion(~1.9)にて、splitメソッドの引数が正規表現と文字列で振る舞いが異なるものがあるため charを使った方が安全という歴史的背景があるようです
ruby2.0以降を使っていれば問題なさそうですが、charsを使うように心がけたいです
Style/NegatedIfElseCondition (from 1.2)
# bad
!x ? do_something : do_something_else
# good
x ? do_something_else : do_something
否定を条件式にしない方がいいですよというものですね
これはたまにやってしまっていてレビューで指摘されていたのでrubocopで拾ってくれるのは地味に助かります
終わりに
gemのupdateはどうしても億劫になってしまいがちですがrubocopを日頃からアップデートしておくことで
将来チームにメンバーが加わった時でもコードのキャッチアップやレビューが簡単になると思います
また独自ルールも設定できたりするのでチーム開発では必須のgemなんじゃないかと思います
余談ですがVScodeを使用している方はruby-rubocopというエクステンションが便利です
わざわざrubocopを実行しなくてもファイルをsaveするたび自動でそのファイルをrubocopにかけてくれて
怒られていたらその行にニョロニョロをつけてくれます
