Sonar Rules !

Sonar 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’

I’m using the sonar compare profiles feature to show some of the rules I’ve modified to enforce quality rules I consider harmful.


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 java.sql.DriverManager

Complexity hack

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

By default, the blocker category is empty. Feel free to add your quality priorities in this one.

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 ... Instantion.

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 System.out.println, e.printStacktrace(), Preserve Stacktrace, 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 ?

  1. #1 by Kavi on September 29, 2014 - 8:00 pm

    How does a developer ( or for that matter any authorized user ) ignore a coding rule violation ? Say a rule “xyz” pops up , is there a way he/she can declare it a false positive and click on some button which ensures that further instances of that coding rule violation are not displayed ?

    If this is not possible, is there a document which explains how Sonar applies rules to code , so that I can manipulate the way it works . Thanks !

  1. Sonar Rules ! | Sonar Quality Platofrm |
  2. Sonar Rules ! | DevOps in the Enterprise |
  3. Through the eyes of sonar: recap. | Don't Make the Same Mistake Twice

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: