Metrics/BlockLength is overreaching

[NobodysNightmare]

Context

The newly introduced Metrics/BlockLength filled a gap that existed in rubocop: Being able to write extra-ordinarily long blocks without a violation.

Now, by default, rake tasks and sinatra gets need to be within 25 lines to be okay.

However, since blocks are used in many different contexts, it seems to be harsh to limit all of them to 25 lines. E.g. I would currently disable the cop because it also affects my rails routes.
In the default settings it has already been disabled for RSpec directories.

Categorizing blocks

I can make up at least three categories of blocks:

• control statement sized blocks (each, map, etc.)
• method sized blocks (task, get, it, etc.)
• class/module/namespace sized blocks (namespace, RSpec.describe, routes.draw)

IMO those need to be treated separately, otherwise people will simply disable the cop, because of too many "false positives".

Solution (?)

I had two ideas in mind how to solve that issue:

1. whitelist some keywords to be allowed to violate the Max setting
   • i.e. not checking those at all
   • this is basically a "disable this cop for methods called X"
2. have different limits/settings for different keywords?
   • this would allow more fine grained control
   • but I have no good idea how the configuration would look like

The idea behind both solutions is, that I don't need to disable the whole cop, but that I can keep it enabled for the important cases and disable/weaken it for the other cases.

What do you think? Are there other/better ideas on how to handle this?

[Drenmi]

I personally think excluding entire files that are pure DSLs, like Rails routes.rb or RSpec spec files, and use the inline disabling for DSLs that go inside a regular class, like an aasm state machine declaration in a Rails model.

One problem with the proposed addition is that any number of classes can implement a method that takes a block, with the same name, creating room for a lot of false negatives.