rubocop: Disable/Enable cops on blocks of code
It would be nice if we could do the following.
# ...
# rubocop:disable ...
def foo
# ...
end
# ...
This would only disable the cop for the block (method) foo. This removes the need to reenable the cop manually.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 23
- Comments: 22 (6 by maintainers)
I think the bigger problem occurres if someone misses
rubocop:enableafter disabling rubocop for a block of code. I’ve recently worked with java, it has such annotations/comments for disabling linters for next method/line. I think much of other tools have the same, because it’s convenient and safe.I even think that this should be harder to disable linter for the rest of file as it’s not the default behaviour most people want (or should want) to avoid unchecked issues. And
rubocop:disableshould disable linter only for the next line.Agree with printercu: rather than disabling for “file”, disabling for “next” is by far the most commonly desired behaviour.
I’ve been assuming all this time (well, up to the appearance of Lint/MissingCopEnableDirective) that rubocop:disable was scoped to the current block.
My experience has been the same as dmolesUC3. I would much prefer the linter to only be disabled for a single line (or the current block) following a disable directive.
I’m unsure how difficult it would be to implement but what about a scenario where the linter is only disabled for the next line unless an enable directive follows it? That gives the best of both worlds and allows Lint/MissingCopEnableDirective to be removed,
I’d like to throw in 2c worth of demand for this. It seems very easy to forget to rubocop:enable after doing a disable for a temporary ignore Also, if the code order is changed, there’s another thing that needs to be checked for.
I’d prefer a different word than block, since block has a special meaning in Ruby, and it doesn’t mean a method. The best I can come up with is
# rubocop:disable_scope.perhaps
# rubocop:disable_block ...Not a big problem if you ask me. I worry that
rubocop:disable_nextwould add complexity both for users and contributors of RuboCop without improving functionality much.