New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lint/UselessMethodDefinition marks empty initialize
with arguments as a violation
#8626
Comments
I've run into a similar issue using the following code: class HttpBaseError < ::StandardError
DEFAULT_MESSAGE = 'A server error has occured'
def initialize(msg = self.class::DEFAULT_MESSAGE)
super
end
end
class BadRequest < HttpBaseError
DEFAULT_MESSAGE = '400 BadRequest: Your request was not valid - please make corrections before trying again'
end
# etc... |
Basically every break is a false positives due to rubocop/rubocop#8626
Here's another example, similar to @jtannas above, except with keyword arguments: class MyClient < Client
def initialize(token: MY_TOKEN)
super
end
end
class Client
def initialize(options={})
# .. uses options[:token] ..
end
end
|
@jtannas & @jaredbeck: cases with default arguments (keyword or not) have been fixed by #8659. I think the case of @andycandrea should not raise an issue (from this cop) as it doesn't call |
In our code base, we had two occurrences of this warning, which were incorrect. We're dealing with a lot of duck typing, where we have many classes, that provide the same API, but are used in different contexts. E.g. we have noop classes, that can be used like their regular counter parts but they don't do anything. class Base
# not defining `initialize`, therefore depending on Object's default initialize w/o arguments
end
class RegularSub < Base
def initialize(item)
super()
@item = item
end
end
class NoopSub < Base
def initialize(_item)
super()
end
end
class NoopAgain
def initialize(_item); end
end For both Disclaimer: I'm fine with adding a |
Right. As I stated, I think the case to be detected are single calls to Note: you will get an offense from another cop about not calling I imagine that @fatkodima will want to tweak this himself, but otherwise I'll do it :-) |
@marcandre Agreed with your points.
Yes, please, do it 😄 |
Thanks for taking the time to look at the example and for providing feedback. It's great if these get changed.
I don't think so as |
Oh right, I missed that. |
…ition`. Note that not calling `super` at all from `initialize` is left to `Lint/MissingSuper` cop.
Basically every break is a false positives due to rubocop/rubocop#8626
Hi Rubocop team,
I just upgraded to Rubocop 0.90.0 and enabled the
Lint/UselessMethodDefinition
cop. After running it on my application, I came across a case where I find this cop's current behavior a little misleading: it marks emptyinitialize
methods that accept arguments as a violation even though it's different from the defaultinitialize
in that it does accept an argument. I'm guessing the cop only looks at the method's body, not whether it takes arguments.Expected behavior
Lint/UselessMethodDefinition
would not mark an emptyinitialize
method that takes arguments as a violation (or would at least offer configuration to mark such cases as valid).Actual behavior
Lint/UselessMethodDefinition
marks emptyinitialize
methods that take arguments as a violation even though they differ from the defaultinitialize
by accepting arguments.Steps to reproduce the problem
RuboCop version
$ bundle exec rubocop -V 0.90.0 (using Parser 2.7.1.4, rubocop-ast 0.3.0, running on ruby 2.6.2 x86_64-darwin18)
Thanks!
The text was updated successfully, but these errors were encountered: