Rubocopのルールにある、otherの意味（と対策）

Question

Rubocopを使ってRubyプロジェクトのスタイル管理などを行っているのですが、そのルールの中にNaming/BinaryOperatorParameterNameというものがあります。

これは、こちらのスタイルガイドにもあるように、「（[]や<<を除く）2項演算子を実装するときには、仮引数名をotherにする」というものです。

もちろん、普通の数値演算などであればotherで特に問題ないのですが、時刻や（Rubyにはないですが）ポインタに対する加算のように、「別の種類の値しか足し算できない」ようなものについては、otherを使うことで逆にわかりにくくもなるように思えます。

ここで質問なのですが、

1. 「このような状況でもotherを使うべき」なのでしょうか、それとも「別種の値であれば名前を変えるべき」なのでしょうか。
2. 名前を変える場合に、Rubocopのエラー対策としては「Naming/BinaryOperatorParameterName自体を止める」「演算子実装のところで#rubocopコメントを入れる」など、どのような方法が適切でしょうか。

なお、「プロジェクト内に確立したコーディング規約はない」という条件で考えていただければ幸いです。

Answer 1

こんにちは。

「このような状況でもotherを使うべき」なのでしょうか、それとも「別種の値であれば名前を変えるべき」なのでしょうか。

「名前を変えるべき」でしょう。
残念ながら、このような別種の値を受け取るようなケースと、同種の値を受け取るようなケースをRuboCopは区別することができません。
そのため、このようなナンセンスな警告がRuboCopでは発生してしまいます。
RuboCopを盲信するあまりナンセンスなコードになってしまっては意味がないので、このような場合は適宜警告を無視するのが適切でしょう。

名前を変える場合に、Rubocopのエラー対策としては「Naming/BinaryOperatorParameterName自体を止める」「演算子実装のところで#rubocopコメントを入れる」など、どのような方法が適切でしょうか。

これについてはケースバイケースになると思います。

「Naming/BinaryOperatorParameterName自体を止める」場合はには、「誤った警告に煩わされることがない」「# rubocop:disable ... コメントがコード内に入らない」などのメリットがあります。
ですが、本当に警告を出してほしい場合にも警告が出なくなってしまうため、プロジェクトとして「この項目は検査するほどでもないだろう」という共有が出来た場合に無効にすべきだと思っています。

「演算子実装のところで#rubocopコメントを入れる」場合には上記の例とは真逆の効果となります。
disable用のコメントはコード中に入ってしまいますが、コードの他の箇所に関しては問題なく検査を続けることが可能です。

また、第3の選択肢として、RuboCopと連携するツールを使う、というものがあります。
例えばreviewdogというツールを使うと、CIでRuboCopを動かし、その警告をGitHub上にコメントとしてつけることが出来ます。これにより警告をGitHub上のコメントとしてみることが出来るため、警告が出るようなコードが存在していても気にならなくなります。

また、(私が開発に関わっているサービスなので宣伝になってしまい申し訳ないのですが)SideCIというサービスを使うと、SideCI上でRuboCopを実行し、今回の例のような誤った指摘はSideCIのUI上から無視することが出来るため、コード中にdisable用のコメントを埋め込むことなく誤った指摘を無視することが可能です。

エラー対策としては、プロジェクトの方針や検査の種類によって最善の方法は変わってくるので、適宜よさそうな方法を選択するしかないかなーと思っています。

Comments

[maisumakun]

ありがとうございます。「ツールが万能でない」のは重々承知なのですが、もっと深い意味があるのかなと気にしてしまいました。