-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
[Fixes #12358] Add does
as a forbidden prefix to Naming/PredicateName
#14032
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
Conversation
The original issue (and the style guide) suggested forbidding These are the offenses added in rubocop itself if
In all cases, "can" is a shorter way of saying "allowed to", and to rename those methods would result in a longer name (eg. |
def could_be_ip?(str) | ||
def potential_ip?(str) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While checking for can/could
prefixes I came across this which I think is a good candidate for removing could
without adding complexity.
All reactions
-
👍 1 reaction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I often use names like maybe_ip?
in such cases. (habit from a lot of Lisp programming)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing with maybe
is that it's just hiding another auxiliary verb (may) 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, yeah - this was just a random comment. 😀
I opened rubocop/ruby-style-guide#959 to tweak the style guide wording of this rule as well. |
My apologies for randomly chiming in. - def can_be_ignored?(token1, token2)
+ def ignoreable?(token1, token2)
- def can_simplify_conditional?(node)
+ def conditional_simplifiable?(node)
- def can_forward_all?
+ def all_forwardable?
- def can_be_made_endless?(node)
+ def possible_with_endless?(node) make any sense? I do not insist on adjusting this, or insist those are in any way better. Just to spark a discussion, and to avoid rushing an amendment to the style guide. For the context, the original PR for the style guide. On the referenced Auxillary very wikipedia page, "can" is used in two cases:
Pretty sure that in many cases, e.g. when expressing a question or a doubt, "can" is a useful prefix. But is it unavoidable? |
@pirj thanks for your comment! As I mentioned in my proposal to the style guide (perhaps not effectively enough!), although "can" definitely can be an auxillary verb, it also can relate to "is allowed to". Authorization frameworks (such as cancancan) use Imagine you were creating a class to represent the player in a game. How would you rename
And although "able" can be used as a suffix, it can become awkward (eg. in Furthermore, the offense messages that are created are definitely wrong:
Which would mean to support can we'd need to write an exception for it (and probably would run into trouble quickly, a la rubocop/rubocop-rspec#2058). Note that these sorts of rewordings are explicitly used in the current style guide too ( |
I'll merge this and we can discuss the situation with "can" separately. |
No tests are added since the tests are not using the default configuration.
Fixes #12358.
Before submitting the PR make sure the following are checked:
[Fix #issue-number]
(if the related issue exists).master
(if not - rebase it).bundle exec rake default
. It executes all tests and runs RuboCop on its own code.{change_type}_{change_description}.md
if the new code introduces user-observable changes. See changelog entry format for details.