is an open platform to manage code quality.
Rules, alerts, thresholds, exclusions, settings…can be configured online. By leveraging its database, Sonar not only allows to combine metrics altogether but also to mix them with historical measures. Let’s see the rules I’ve selected through the compare profiles feature.
Compare profiles with ‘Sonar way with Findbugs’
As you see I made some changes to the default ruleset.
Only in my profile
Most of these rules aren’t standard in sonar. One of the great feature of sonar is to define architectural constraints. From my previous post you may know how
java.util.Date can harm your application and how joda can help you. That’s why I’ve defined architectural rules to banish the jdk date representation from my codebase. You probably know that it’s a bad idea to do raw jdbc calls without effective connection pooling that’s why I’ve added the avoid the
By default Sonar checks cyclomatic complexity of methods against a specified limit. The complexity is measured by the number of if, while, do, for, ?:, catch, switch, case statements, and operators && and || (plus one) in the body of a constructor, method, static initializer, or instance initializer. It is a measure of the minimum number of possible paths through the source and therefore the number of required tests.
Generally 1-4 is considered good, 5-7 ok, 8-10 consider re-factoring, and 11+ re-factor now !
In practice, if you add some logging to a considered maintainable method you end up easily to 12. I know you can refactor your code to extract the logging or review it but I’m not a cyclomatic complexity paranoid.
My rule of thumb is if a method don’t fit in a small screen… refactor it !
When you inherit some legacy code, you will perhaps relax at some point these levels of expectations. What I wanted is to consider 25 of cyclomatic as no go for production (
blocker) and 12 as a
critical issue. The trick is to use the 2 rules instances of sonar (pmd and checkstyle) to attain the desired behavior : enable them both at the same time, modify the severity and expected levels.
Please don’t apologize to have high standards : #sonar
Blocker for ‘easy to fix’ , effective bugs, maintenance nightmares
The easy to fix issues should be fixed as they are produced. In this category I have put most of immutable rules improvement from jdk 1.5
valueOf(...) with all rules like
In the same category you can put the
unused imports and
... Must Use Braces that can be fixed automatically using eclipse save actions
Findbugs and pmd are also really good at locating effective bugs like
Correctness - Impossible downcast of toArray() result or
Broken Null Check
In the maintenance nightmares, I’ve put
equals/hashCode contract violations. You can perhaps also add
Avoid Catching NPE
Depending on my personal tastes, effective risk and false/positive ratio on our codebase, I’ve modified some severity levels.
I’ve also disabled most of final methods/class rules that often break spring aop or hibernate proxying mechanisms.
Make violation results more visible
The first step to eliminate your weaknesses is to realise that they exist and name them.
By default I found sonar too green (at least for Rules compliance radiators). Psychologically, you think the situation isn’t that bad. In sonar, you can highlight the sonar results (so have more nuanced colors : red, yellow, green) by modifying the weight of violations.
Don’t be afraid to show the wall of shame… strangely it affects positively developers and the quality of their projects. You don’t want to own the project in red
You can also use the alerts to show expected levels.
And now your feedback is welcomed,
what are your sonar recipes,
the rules that you would add in the blocker category,
a better idea about threshold for alerts ?