[Fix #13150] Allow `get_!`, `set_!`, `get_?`, `set_?`, `get_=`, and `set_=` in `Naming/AccessorMethodName`
Fixes #13150.
This PR allows get_!, set_!, get_?, set_?, get_=, and set_= method names in Naming/AccessorMethodName.
Names ending with !, ?, or = are not appropriate as attribute names.
$ ruby -e 'class X attr_reader :x! end'
-e:1:in 'Module#attr_reader': invalid attribute name 'x!' (NameError)
class X attr_reader :x! end
^^^^^^^^^^^
from -e:1:in '<class:X>'
from -e:1:in '<main>'
Therefore, they don't need to be recognized as intended accessor method names.
Before submitting the PR make sure the following are checked:
- [x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
- [x] Wrote good commit messages.
- [x] Commit message starts with
[Fix #issue-number](if the related issue exists). - [x] Feature branch is up-to-date with
master(if not - rebase it). - [x] Squashed related commits together.
- [x] Added tests.
- [x] Ran
bundle exec rake default. It executes all tests and runs RuboCop on its own code. - [x] Added an entry (file) to the changelog folder named
{change_type}_{change_description}.mdif the new code introduces user-observable changes. See changelog entry format for details.
FTR, I think you should also include =.
@akimd Sure! I've updated this PR.
I get allowing ! for assignment and = for setters, but I don't get the other cases. Why would someone name methods in such a way - it doesn't make any sense to me.
I think none of us would use them. But the point here is that this cop promotes using regular attribute syntax for accessors, and these special cases aren't accessors. For some reason someone wants to flag them for some specific weirdness (like my original get_min! which is costly and I didn't want to look innocuous).
In fact I think the title of this MR is slightly misleading, it is not about "allowing them as accessor names", but rather "stop considering them as accessor names".
In fact I think the title of this MR is slightly misleading, it is not about "allowing them as accessor names", but rather "stop considering them as accessor names".
Good point - admittedly I was mislead by the title of the PR.