10000 [Fixes #12358] Add `does` as a forbidden prefix to `Naming/PredicateName` by dvandersluis · Pull Request #14032 · rubocop/rubocop · GitHub
[go: up one dir, main page]

Skip to content

[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

Merged
merged 1 commit into from
Mar 26, 2025

Conversation

dvandersluis
Copy link
Member

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:

  • The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (if the related issue exists).
  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
  • Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

@dvandersluis
Copy link
Member Author

The original issue (and the style guide) suggested forbidding can as well, but I'm not sold that this would be a positive change.

These are the offenses added in rubocop itself if can is forbidden:

lib/rubocop/cop/layout/space_inside_parens.rb:161:13: C: Naming/PredicateName: Rename can_be_ignored? to be_ignored?.
        def can_be_ignored?(token1, token2)
            ^^^^^^^^^^^^^^^
lib/rubocop/cop/lint/empty_conditional_body.rb:94:13: C: Naming/PredicateName: Rename can_simplify_conditional? to simplify_conditional?.
        def can_simplify_conditional?(node)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
lib/rubocop/cop/style/arguments_forwarding.rb:465:15: C: Naming/PredicateName: Rename can_forward_all? to forward_all?.
          def can_forward_all?
              ^^^^^^^^^^^^^^^^
lib/rubocop/cop/style/endless_method.rb:221:13: C: Naming/PredicateName: Rename can_be_made_endless? to be_made_endless?.
        def can_be_made_endless?(node)
            ^^^^^^^^^^^^^^^^^^^^

In all cases, "can" is a shorter way of saying "allowed to", and to rename those methods would result in a longer name (eg. allowed_to_be_endless?) or an awkward wording (eg. all_forwardable?) that is less clear than the original.

def could_be_ip?(str)
def potential_ip?(str)
Copy link
Member Author

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.

Copy link
Collaborator

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)

Copy link
Member Author

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) 😆

Copy link
Collaborator

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. 😀

@dvandersluis
Copy link
Member Author

I opened rubocop/ruby-style-guide#959 to tweak the style guide wording of this rule as well.

@pirj
Copy link
Member
pirj commented Mar 25, 2025

My apologies for randomly chiming in.
Just by looking at the method names, without knowing all context, would the following

- 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:

  1. "I can swim"
  2. "Such things can help"

Pretty sure that in many cases, e.g. when expressing a question or a doubt, "can" is a useful prefix. But is it unavoidable?

@dvandersluis
Copy link
Member Author
dvandersluis commented Mar 25, 2025

@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 can in this way, for instance.

Imagine you were creating a class to represent the player in a game. How would you rename can_move_forward??

can_forward_all? is another good example. The method asks, "can the method forward all its arguments" (or, is argument list able be replaced with ...). all_forwardable? is considerably less clear (what is "all" here?). all_args_forwardable? is perhaps better, although I think there are distinctions that become less clear (ie. def foo(a) all args are forwardable, but it cannot be foo(...) necessarily).

And although "able" can be used as a suffix, it can become awkward (eg. in conditional_simplifiable?, simplifiable is questionably an English word, it is not defined in the OED or Merriam Webster dictionaries, to choose two).

Furthermore, the offense messages that are created are definitely wrong:

C: Naming/PredicateName: Rename can_simplify_conditional? to simplify_conditional?.

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 (can_play_basketball? becomes basketball_player?)

BD90

@bbatsov bbatsov merged commit d09e469 into rubocop:master Mar 26, 2025
24 checks passed
@bbatsov
Copy link
Collaborator
bbatsov commented Mar 26, 2025

I'll merge this and we can discuss the situation with "can" separately.

@dvandersluis dvandersluis deleted the issue/12358 branch March 26, 2025 13:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve Naming/PredicateName cop
3 participants
0