[Lint] Suppress redundant rules for IDE

Hey there, let me first say, that Sonar is a very great tool and let me thank you for all the effort, you put into it. Thank you very much!

Now for my suggestion: It would be great, if there was at least an option, if not always on to suppress Rules in SonarLint, that are redundant to what Eclipse already checks. Of course many of these rules make a lot of sense in SonarQube. But if you’re binding Lint to Qube all these Rules, that are completely redundant to the Eclipse internal rules just flood your problems view.

I guess, this would mean to query the eclipse preferences, as rules may have been aded/removed compared to the default. And this would mean to stay tuned to the actual version of Eclipse in use.

What do you think?

Of course this also applies to other IDEs as well.

Hello @mfroehlich,

Welcome to the SonarSource community forum and thanks for the nice comments on our products.
What you ask seems difficult to achieve for many reasons:

  • The purpose of the connected mode (binding Lint and Qube) is that the developer will work with a linter ruleset that’s an almost perfect image of the rules standards defined centrally in SonarQube. He knows that complying to SonarLint will have him (almost) comply to the SonarQube scan downstream.
  • You can never guarantee a 1-to-1 correspondance of rules defined by one tool and another. Even if they look the same from the outside, and they overlap on a large part, they necessarily implemented differently and may behave different on special cases.
  • We would have to inventory the Eclipse rules, for each different Eclipse version and configuration… What a job ! We prefer to keep implementing nice new rules :slight_smile:
  • … Probably other reasons…

Hope that makes sense, Feedback is welcome.


1 Like

Yes, I totally understand. Then only the most obvious ones really should be disabled in Lint, because every modern IDE will implement them. And the implementation will always lead to the same result.

These are:

S1128, S2959, S3985, S1068, S1144, S1481, S1172
S1220, S2293

Also there are S2095 and S2093, which should be somehow merged into one rule and also fall into the list, that should be deactivated in Lint.

Apart from that I agree, that analysing every new version of Eclipse should be avoided and more tests to be disabled in Lint is not up to you to find out.

1 Like

Hi @mfroehlich,
for projects bound to a SonarQube server, we think that SonarLint should enforce, as much as possible, the same ruleset as SonarQube, so that developers know that if SonarLint does not detect an issue while they code, there are good chances SonarQube will not raise new issues as well (although there are a few exceptions to this…)
Thus, at least in the short term, we do not plan to add the possibility for a rule to be only activated in SonarQube but not in SonarLint for projects bound to a SonarQube server.
On the other hand, we understand that some rules may create noise as they are already built-in in the IDE itself - so for projects that are not bound to SQ, we may review whether certain rules should be activated by default or not.
Thanks for the above valuable feedback, we are going to keep this thread open to gather feedback and votes from more community users.