Sonar: better rules for java projects

Question

I am trying to find a better alternative to the default java quality profile "Sonar way with Findbugs".

Among the 516 rules of the profile, some of them are not actually set up properly (priority or activation).

For example:

• Is "Dead store to local variable" really a critical issue?
• "Add empty string" is disabled but is worth enabling.
• "Use Equals To Compare Strings" is disabled...

As I could not find any ready-to-use set of rules better than the default one, I would like to get feedback on this topic from experienced Sonar users.

Answer 1

My experience (I'm using SQ since its first release in 3 different companies, wrote 130+ custom checks over the years) is the following:

• create a profile P1 that is a copy of current "SonarQube Way" profile
• in this profile remove all rules that are irrelevant to your context (mostly if you have a custom rule that conflicts with an off the shelf rule) and change priority if required (try only to increase priority if your context requires it.) Keep track of the reasons for having modified the profile. The point here is to be able to say "we follow the off the shelf configuration except for some specific cases where we want a more strict control". This profile will be used to easily compare your current "SonarQube Way" profile with a newer one.
• create a profile P2 that inherits from P1 and adds other rules, be they custom or not. Work on this topic with your development teams in order to have a consensus.
• keep as much as possible the default priority of rules you add (don't give food to the people wanting to argue that your configuration is flawed, and if you need to change a priority be ready to defend your decision, see next point.)
• for all rule priority changes (off the shelf and/or custom rules), follow a predefined scale (for instance this one) and stick to it.
• make P2 the default profile.

Then each time "SonarQube Way" evolves you can easily update it, then compare it with P1.

You can do exactly the same using "SonarQube Way with Findbugs" profile (but I wouldn't do it as this enables lots of rules...)

Always keep in mind that it's better to have fewer rules you can explain and all developers are willing to apply instead of having lots of checks that are difficult to explain, nobody believes in and nobody wants to apply, nor read SQ anymore due to the huge amount of checks. In other words, start small and grow with your fellow developers.

Also remember that issues that are not fixed (and nobody wants to fix due to the fact that he rule raises too many false positives, is difficult to understand, etc) are a debt that is difficult to get rid of. This is a leak that will always bring more debt mostly because people are not ready to hear about such issues. It's better in such a context to deactivate these rules and bring them back later, when people are ready to talk about them and apply them.

Last but not least. Agree with the development teams on quality profiles release dates. Lets say for instance that you agree on the fact that there will be two profile updates per year. Between two profile releases people are welcome to discuss the rules, but these will not be modified until next release, if a modification is wanted (addition/ deletion of rules), it has to be discussed and a consensus has to be found. If a project starts between two releases it starts with current profile and uses it. When the profile is updated, your projects may have one release to align their code with the new rules, or if you use the "fix the leak" approach, projects agree that new code as well as refactored code will follow the new profiles.

Remember that if you're the owner of the profiles, your developers should be the ones asking for new rules to be added (this is a good KPI by the way.)

There is a lot more to say about this, but this should be a good starting point in order to help you.