Hi @mfroehlich
There is in fact an existing thread for your first feature request, with a suggested workaround that we think is easy enough to make the topic low priority on our side (which doesn’t mean we won’t do it :).
I encourage you to vote/watch this thread.
Regarding the rule specific feedback (thanks again), we had discussions in the team, that I will try to sum up.
Some rules are annoying when you are in the middle of editing code
This issue is common to most linters/compilers AFAIK.
https://www.commitstrip.com/en/2020/06/11/im-watching-you/
Your suggestion to have 2 analysis modes, where some rules are only checked in the “full” mode is not in our plans. We want to help developers to find issues as soon as possible, and not relying on the developer to remember to run a manual scan before pushing code.
If this is at the cost of some false positive issues being displayed during a short moment, for now we consider this to be acceptable.
FIXME, TODO, deprecated code related rules are duplicating existing IDE features
We agree those rules can be too verbose, and with low value if IDE already handle those concepts. We plan to disable them by default. Of course, if using connected mode, the configuration from the server will still apply, to ensure consistency with SonarQube.
https://jira.sonarsource.com/browse/SLE-389
Controversial rules (java:S2786, java:S2333)
We already did a big effort to remove most controversial rules, but there will always been some disagreement. We consider those rules as educational, so we prefer to keep them on by default. Of course you can disable them in your own quality profile.
Adding filtering capabilities to hide minor/info rules temporarily could also help. If you are interested I encourage you to vote for:
https://community.sonarsource.com/t/filter-sort-on-issue-type-severity/2127
Never change a running system (cognitive complexity, too many method parameters, …)
We can only agree. We have to rethink/improve the concept of leak period in SonarLint. Not scheduled this year but definitely a topic we are interested to work on. You can watch/vote for:
https://community.sonarsource.com/t/detect-leak-using-sonarlint/31586
Code patterns used to improve the debugging experience
We tend to disagree with such practices, especially if it can hurt maintainability/readability. But that’s also a bit opinionated. You can of course decide to disable those rules.
Support of Eclipse specific @SuppressWarnings()
In particular @SuppressWarnings(“unused”). Nice suggestion.
Ticket created: [SONARJAVA-3558] - Jira
Declaring RuntimeException to be thrown (java:S1130)
We tend to agree with the documentation benefit, so we will change the rule:
https://jira.sonarsource.com/browse/SONARJAVA-3559