Provide thresholds ontop as recommendations instead of failing hard on issues

[OneDivZero]

Problem

Default settings are mostly sophisticated and often really frustrating. This has nothing to do with real issues, if you are an experienced developer. So actually my class has now e.g. for 'Metrics/MethodLength' currently 3+ lines over rubocops recommendation. I had done every possible optimization ... and now?

Thoughts

• First thought: GFY rubocop (bad experience for a supporting tool)
• Second thought: Something extractable or refactorable?
• Third thought: Nope, this class is fine, but only has 3 lines over the top

So what should I do now ?

• Put everytime an annoying disable-statement on top of the class
• Or just silence rubocop by changing the max-value via config
• Problem: the latter is globally applied ... maybe not a good ideal!

Solution:

You all know soft-quotas and hard-quotas from filesystems ... this is an easy concept!
So we just can add another keyword to the yaml-config named :quota beside existing :max ...

Or maybe rethink the whole stuff accoding to having a quota-warning in general, with some tolerance instead of hard-failures (esp. inside ci-pipelines)! Recap there is also a social aspect, which covers learning-theories ontop. Let us make devlopers feeling good every day, instead of feeling sadly, cause rubocop fails again.

My thoughts are overwhelming a plain technical discussion ... Feel free to comment your personal thoughts!

[dvandersluis]

I've been thinking about this, but I'm not sure how it would work practically. How would a soft limit function? If it doesn't raise a warning then it might as well just be the hard limit anyways, and if it does raise a warning, then is it any different than what you're currently running into?