Let rules with quantitative parameters indicate the violation severity

There are many rules with thresholds based on quantitative parameters, e.g., the number of classes in a package. Besides the threshold, all rules have severity. There is no link between severity and a threshold however.

I’d argue that in the case of such rules exceeding the threshold significantly should be more severe than exceeding it just marginally. In other words, exceeding the threshold twice is likely a big problem, while just reaching it is a signal to plan a corrective action. Note that linking thresholds and severity can play nicely with quality gates. A marginally exceeded threshold might not make the issue severe enough to let the gate fail, on the other hand letting the issue go worse would eventually raise its severity enough and lets the gate fail.

The suggestion is to extend the configuration of rules with such thresholds to reflect how much the threshold was exceeded. For instance, there might be several increasing thresholds with increasing severities. To make the configuration easier, it could be perhaps possible to enter just the lowest and highest threshold and the severities between the threholds’ severities could be simply interpolated.

As an example, let’s have the rule of number of classes in a package. It could be configured to indicate an info problem on 30 and major issue on 100 (i.e., having these two thresholds specified in the configuration). So a package with 30 classes would make an info issue, when the number of classes exceeds 75, the issue is reported as minor and over 100 it becomes a major issue.

I hope I wrote it clearly enough :slight_smile:

Hi @pdolezal,

Thanks for the suggestion.
If I’m correct, it ties with the idea shared in this other thread: Make copy of the rule - #4 by virshu

We are making a note out of this suggestion and are monitoring the traction on the topic.

1 Like

Hi @Chris,

the idea goes in a similar direction – just instead of copying a rule with different parameters, I suggest rather to allow rules to have multiple thresholds. But which way the goal would be achieved is a technical detail (and the question of the user experience, of course).

A recommended approach is mentioned in the thread that you linked, which is adjusting the threshold. Well, it is hardly usable for our case. We have lower hundreds of projects and we have a single rule set for each language that we use, because it is basically not feasible to make adjustments for individual projects. Having smarter or more flexible rules would be then really helpful.

Thanks for the explanation about your context.