Skip to content
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

Customizing the preference of has_key? vs key? #3428

Closed
roberts1000 opened this issue Aug 18, 2016 · 8 comments
Closed

Customizing the preference of has_key? vs key? #3428

roberts1000 opened this issue Aug 18, 2016 · 8 comments

Comments

@roberts1000
Copy link
Contributor

roberts1000 commented Aug 18, 2016

Matz and rubocop prefer key? and value? to has_key? and has_value?. This is a step backwards in readability. People rarely walk up to another person and just say key?, but when they do, they also give some other cue like holding out a hand or inflecting their voice. Simply saying key? is ambiguous as it could mean "do you have the key?", "did you ever have the key?", "can I have the key?", etc...

IMHO, adding a question mark to the end of a method is not a substitute for dropping a meaningful prefix, but rubyists have a convention of dropping "is" and "has" from the start of method names and many people like it.

I'm trying to configure this cop to prefer has_key? and has_value?, but I'm not sure if this is possible. (I don't want to disable it outright because there may be other method suggestions that I would like to know about in the future.) I didn't see an example of how to customize this in the config/default.yml, so I tried customizing this with :

Style/PreferredHashMethods:
  PreferredMethods:
    key?: 'has_key?'
    value?: 'has_value?'

I got the following error output

Warning: unrecognized parameter Style/PreferredHashMethods:PreferredMethods found in /home/me/Documents/dev/foo/config/rubocop.yml

Is customizing this cop supported?

RuboCop version

0.42.0 (using Parser 2.3.1.2, running on ruby 2.3.1 x86_64-linux)

@bbatsov
Copy link
Collaborator

bbatsov commented Aug 24, 2016

This cop is not configurable, but I agree that it should be.

@rrosenblum
Copy link
Contributor

I thought that has_key? was deprecated? It seems like there is a bit of churn back and forth on if it should be deprecated or not. Either way, it has been several years and there doesn't seem to be any progress in someone actually removing the methods if they in fact deprecated.

@roberts1000
Copy link
Contributor Author

In this thread, Matz mentions that it won't be removed (even in Rails 3). At this point, it's not really deprecated. The Ruby team prefers key? to has_key? which is probably why key? has ended up as the rubocop recommendation. As someone pointed out in this thread key? doesn't really make sense. hash.key? reads to native English speakers as "hash, are you a key?", not "hash, do you have a key?". has_key? is preferred for clarity and readability.

@ghost
Copy link

ghost commented Oct 2, 2016

I would like to tackle this issue for hacktoberfest.

@bbatsov
Copy link
Collaborator

bbatsov commented Oct 2, 2016

Great!

@ghost
Copy link

ghost commented Oct 6, 2016

Sorry. I feel like I overcommitted in the moment. I haven’t had time to work on this issue. I wanted to let you all know. Thanks.

@Drenmi
Copy link
Collaborator

Drenmi commented Oct 7, 2016

@johndavidmartinez: Don't worry about it. You're welcome back when you think you have the time. 😀

@abrom
Copy link
Contributor

abrom commented Oct 7, 2016

Hope you don't mind @johndavidmartinez, just came across this earlier and was keen to see it included. #3579 includes options for short (default) and verbose hash function name styles.

abrom added a commit to abrom/rubocop that referenced this issue Oct 8, 2016
…with short (default) or verbose method naming
@bbatsov bbatsov closed this as completed in a885410 Oct 8, 2016
Neodelf pushed a commit to Neodelf/rubocop that referenced this issue Oct 15, 2016
…with short (default) or verbose method naming
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants