You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I implemented a class which defined =~. I was basing it off a class internal to Rails, and so I also utilized their parameter name of re. In addition to being too short, to my surprise, Rubocop informed me that I violated Naming/BinaryOperatorParameterName and should name my parameter other. I looked at the Rubocop docs, which linked me to the ruby style guide for the other parameter. It is my understanding that Rubocop is based on this guide.
The style guide states:
When defining binary operators and operator-alike methods, name the parameter other for operators with "symmetrical" semantics of operands. Symmetrical semantics means both sides of the operator are typically of same or coercible types.
Operators and operator-alike methods with symmetrical semantics (the parameter should be named other): +, -, *, /, %, **, ==, >, <, |, &, ^, eql?, equal?.
the style guide then states
Operators with non-symmetrical semantics (the parameter should not be named other): <<, [] (collection/item relations between operands), === (pattern/matchable relations).
I would assume that =~ falls under pattern/matchable relations, but I might be wrong. I would expect in this case, that I would not be in violation of the Naming/BinaryOperatorParameterName cop, especially considering =~ is not listed in the operators and operator-alike methods.
For example's sake, here is the aforementioned method that was in violation:
def =~(re)re.match?(to_s)end
Expected behavior
I expected to not be in violation of Naming/BinaryOperatorParameterName for this method.
Actual behavior
Describe here what actually happened.
Please use rubocop --debug when pasting rubocop output as it contains additional information.
Run the following code with ruby hello.rb to verify it works. Then run rubocop hello.rb and verify that the def =~ method is in violation of Naming/BinaryOperatorParameterName.
# hello.rb# frozen_string_literal: true# Example of Naming/BinaryOperatorParameterName copclassHellodefinitialize(name)@name=nameenddef =~(regex)regex.match?('Zach')enddefself.greet(name)h=new(name)puts'Hello Zach'ifh =~ /#{name}/endendHello.greet('Fred')Hello.greet('Zach')
…ameterName`
Defining the match operator `=~` triggered a false positive for
`Naming/BinaryOperatorParameterName`, which should not be triggered
for pattern/matchable relations according to the [Ruby style guide](https://rubystyle.guide/#other-arg).
I implemented a class which defined
=~
. I was basing it off a class internal to Rails, and so I also utilized their parameter name ofre
. In addition to being too short, to my surprise, Rubocop informed me that I violatedNaming/BinaryOperatorParameterName
and should name my parameterother
. I looked at the Rubocop docs, which linked me to the ruby style guide for theother
parameter. It is my understanding that Rubocop is based on this guide.The style guide states:
the style guide then states
I would assume that
=~
falls under pattern/matchable relations, but I might be wrong. I would expect in this case, that I would not be in violation of theNaming/BinaryOperatorParameterName
cop, especially considering=~
is not listed in the operators and operator-alike methods.For example's sake, here is the aforementioned method that was in violation:
Expected behavior
I expected to not be in violation of
Naming/BinaryOperatorParameterName
for this method.Actual behavior
Describe here what actually happened.
Please use
rubocop --debug
when pasting rubocop output as it contains additional information.Steps to reproduce the problem
Run the following code with
ruby hello.rb
to verify it works. Then runrubocop hello.rb
and verify that thedef =~
method is in violation ofNaming/BinaryOperatorParameterName
.RuboCop version
I would be happy to submit a PR if this is something that should be corrected. If not, thanks for your time!
The text was updated successfully, but these errors were encountered: