-
-
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
Style/OptionHash is possibly overeager #2106
Comments
hey @wli! I did consider that... What would the list be? I started thinking about people programming Ruby using non-English words for variable names and got dizzy |
I can see how maintaining a list can be a nightmare. Maybe you can make an option on the cop for individual projects to specify their own whitelist/blacklist? Then rubocop-the-project doesn't care, but it'll work for more use cases. |
I'm OK with having a list of param names that would trigger the offense. |
@wli I think that's a great idea. Maybe with some safe defaults: |
Just throwing out more ideas for defaults: The default list should be something extremely safe that people aren't going to complain about and then, if they don't want it, they can change it to whatever they want. |
Sounds reasonable. On 6 August 2015 at 12:10, Jeff Felchner notifications@github.com wrote:
Best Regards, |
I took a stab at this: #2114 |
Fixed by #2114 |
First, I know this is disabled by default, so it's not super critical. However, I'd love to enable this cop by default in my projects.
I have the following function signature:
used_photos
isn't an option hash - it actually stores data that we use to calculate certain properties. I could change this to keyword arguments to get around this cop (or locally disable), but it doesn't seem like the right solution.What do you think of changing this so it only errors out for
options = {}
,args = {}
, or some other whitelist of acceptable names?@maxjacobson - this was originally added in #2030
The text was updated successfully, but these errors were encountered: