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)

Most upvoted comments

I think the bigger problem occurres if someone misses rubocop:enable after 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:disable should 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 ...

which is not good, because it splits single instruction

Not a big problem if you ask me. I worry that rubocop:disable_next would add complexity both for users and contributors of RuboCop without improving functionality much.