-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
TrivialAccessors check problem #308
Comments
This behaviour is intentional. Despite the different name this is still an At some point we might introduce some configuration regarding exact name matches. @yujinakayama @jonas054 Would you share your thoughts on the subject? |
Thanks for the fast and clear explanation. Its not what I can directly derrive from the ruby-style-guide. What if I want to keep my |
Even now you can simply instruct RuboCop to skip the TrivialAccessors check for that particular method. |
Thanks, that could be useful (though I strongly dislike having rubocop-specific code in my source code). |
Though I think TrivialAccessors is not perfect, but at least in this case, I don't think the offence is a problem. With the provided information, I wonder why you don't use |
One use case may be duck-typing. You may have to provide a definition |
I have some subclass that overrides a method:
Rubocop thinks this is a
TrivialAccessor
offence, but I tend to disagree. What do you think? I dont think there is an easy way to refactor this into an attr_reader?The text was updated successfully, but these errors were encountered: