Extending a rule description: extension on top, and per quality profile?

[Editing this to change from a question to a new feature request]

Suggested enhancements for the feature of extending a rule description (mainly thinking of built-in rules rather than custom rules):

  1. Make the extension to the rule description something that can be bound to a particular quality profile, much like the rules that can be parameterized for each profile, such as max method count.

  2. Provide a per-rule option to make the extension to the rule description appear at the top of the description rather than the bottom. Alternately, a simpler approach would be to have some text or an icon at the top of the rule description (as shown when clicking on “Why is this an Issue?” or when viewing the description in SonarLint) to indicate there’s a custom extension to the description. (So you’d still have to scroll down to see the extension, but you’d only have to do that when you know there’s an extension.)

My motivation for #2 is that we tell developers that, in general, they are expected to fix anything reported by SonarLint, in the parts of a file they are modifying, before committing their changes. But there are many code smell rules, particularly those of the too-many-blahblah variety, where they are probably good practice most of the time, but there are always exceptions. In other words, we view these more as guidelines rather than hard-and-fast rules. We’d like developers to think about, for instance, whether that method really needs more than 7 parameters (rule java:S107). On the other hand, if the method REALLY needs more, we’d rather not have them do something hideous like bundle some parameters into a new object when they don’t really make sense together, just to satisfy a rule.

So we would like to add a note to that effect by extending the rule description to say, yes, you can break this rule, but you might be asked about it at the next code review, or some such. But it would be nice to see that on top when they click on the description link in SonarLint, or see the “there’s something below” notification (depending on which implementation of #2 you choose). Many of the descriptions are rather long, and developers might complain about having to scroll down every time to see if there’s an extension.

Hi,

First, your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:

8.6 → 8.9.6 → 9.2.4 (last step optional)

You may find the Upgrade Guide helpful.

Regarding your questions, neither of these things is currently available. Feel free to move this topic to the New Features category.

 
Ann

I found this post in a search: SonarLint should show tags of rule It was ultimately closed because the OP said the option was no longer needed. But it would be one way to get what I’m looking for here. That request was to have the tag(s) associated with a rule appear in the popup rule description in SonarLint.

This would help to devs prioritize or triage issues. For instance, we might impose a policy like “you MUST address this issue immediately if it has an owasp tag!”

The other thing we would like to do is turn certain smell rules into “maybes.” Many of the smell rules are “best practices” tips that are good to follow, in general, but NOT if the alternative is worse. For instance, “don’t make a method longer than N lines.” I’ve seen cases (pre-SQ) where such a rule was rigidly enforced, which would cause someone to split a function with a simple, coherent, easy-to-grasp purpose, but N+1 lines, into two pieces, neither of which makes sense on its own, and they end up passing data between the two halves using class fields that have no purpose once the two halves are done.

So we have added our own notes to certain rules, saying something like “this rule is a guideline only and can be violated if…” but right now you have to scroll to the bottom of the rule description to see it. It would be more convenient to see a custom tag at the top of the rule description, that would tell the user that this is one of those special cases.

We would want this to work for custom tags bound to a rule, so I assume this would only work for when SL was bound to the server. (An unbound SL could still display the tags for a rule, but they would be the default tags as known by SL.)

To summarize in one place what I’m requesting:

  • My use case is having certain rules (all smells, most likely) where the rule is a guideline rather than being rigidly enforced. Since there could be a dozen rules like this, we’d need a way for devs to keep track of which rules are “discretionary,” particularly when they’re using SonarLint in their IDE.

  • The mechanism to enable this would be one of (highest preference on top):

  1. Display the rule’s tag(s) in SL – as was suggested in the other post mentioned above – and we’ll use custom tags to mark these special rules;
  2. Make the rule description extension appear above the built-in rule description in the popup in SL, rather than below (either always, or a per-rule option);
  3. Add a special icon or mark to the rule description popup in SL to indicate there’s a custom extension to the rule description (so the dev knows to scroll down).

(#1 would also enable other use cases, such as having devs triage by tags.)

Orthogonal to this is the desire to have the per-rule features above done at the granularity of a project or quality profile rather than globally.

1 Like

Hello @MisterPi and thanks for sharing your use case.
Have you considered overriding the default rule severity in your quality profile instead? For example, you can set rules that you do not want to rigidly enforce as “Info”; the severity level will be synced to SonarLint (except Visual Studio) so that the overriden severity level will be shown when you display the associated rule description (this information is at the top of the rule description).
On a side note, developers can then flag individual issues as “Won’t Fix” in SonarQube, and provide a comment there as well; this will enable those issues not to fail the Quality Gate and also not to be reported in SonarLint again.

1 Like

Well yes, we’re looking at such workarounds. But we’re also considering a second class of rule, which is not rigidly enforced but still requires approval from a code reviewer. (Can’t leave EVERYTHING to devs’ discretion! :slight_smile: )

Distinguishing the two would be easier with a custom tag.

Besides, putting the tag in the rule description in SL would make SL consistent with the SQ web portal, which displays tags in the rule description. (I thought it was just an oversight – was there a specific reason for not putting tags in the description in SL?)