Rubocop: --exclude-limit seems like an anti-feature

[ClayShentrup]

To be clear, this is not a bug.

Last week I set up Rubocop with a todo file with my new employer. I wondered why I wasn't getting more requests for help sorting out violations, and then I discovered last night to my great surprise that many of the rules were completely disabled in the todo file because they had more than 15 occurrences.

This behavior seems contrary to the entire purpose of --auto-gen-config, which is to put a stake in the ground and ratchet down the errors over time. If I wanted to globally disable a rule, it wouldn't make any sense to put it in a todo file, as this would allow the violation to propagate into new files.

To summarize, I think this behavior violates the "principle of least surprise". It also took me some time to figure out why this was happening and how to get the expected behavior. I can't imagine I'm in the minority here.

Thanks

RuboCop version

0.41.1

[metcalf]

Agreed that the default is surprising. We use this feature but at a value of 1000 by default. The current default is probably sane for small projects but definitely doesn't make sense for a million+ line codebase.

[ClayShentrup]

Thanks @metcalf. What I'm saying is that I can't even see the value of this behavior in a _small_ codebase. Because, if you wanted to disable a feature completely, you could consciously do it in .rubocop.yml. The whole _point_ of the todo config is to put a stake in the ground and prevent any more violations. I literally cannot see any reason for --exclude-limit to exist. Or at the very least, I would expect it to be unlimited by default, requiring it to be explicitly passed.

[metcalf]

Ah, yep. I agree that the default should be unlimited (or at least very
high if unlimited can wreck unexpected havoc for some reason).

On Thu, Jul 28, 2016 at 10:05 PM, clay shentrup [email protected]
wrote:

Thanks @metcalf https://github.com/metcalf. What I'm saying is that I
can't even see the value of this behavior in a _small_ codebase. Because,
if you wanted to disable a feature completely, you could consciously do it
in .rubocop.yml. The whole _point_ of the todo config is to put a stake
in the ground and prevent any more violations. I literally cannot see any
reason for --exclude-limit to exist. Or at the very least, I would expect
it to be unlimited by default, requiring it to be explicitly passed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bbatsov/rubocop/issues/3339#issuecomment-236095380,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABBTJYkkCaFBnKyp8HQgty9EkXacOlXks5qaYomgaJpZM4JUU5D
.

[carmi]

Is there a way to define a large or larger --exclude-limit in a config file rather than having to pass it as an argument with each invocation? This would somewhat help to keep the exclude limit higher if not unlimited.

[bilal-khan]

Agreed, just bumped into this and was surprised to see cops disabled. Does not make sense to disable cops in a "todo" list imo.

[bbatsov]

I'll defer to @jonas054 on this one, as I don't recall what was the reasoning behind the current implementation. I'm open to concrete suggestions about how to improve this.

[jonas054]

@ClayShentrup Makes a good point. It does seem like an anti-feature. I've tried to dig through the GitHub history to find what the motivation was originally, but I didn't find anything. My guess is that we wanted a short and readable .rubocop_todo.yml, a goal that I now see as less important than being able to improve the inspected code incrementally.

If somebody wants to change the default to unlimited, that's fine with me.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[stale[bot]]

This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it.

[andyw8]

This was recently mentioned in https://medium.com/@scottm/rubocop-in-legacy-projects-part-1-todos-and-todonts-877ace9f23b7 by @scottmatthewman.