Measuring code quality with Sonar

At JTeam, we continuously strive for good quality code. The reason is very simple: bad quality code slows down the development process. The small investment pays out in even the simplest of projects.

Measuring code quality is not a matter of a single metric. Instead, software quality has many aspects, some of which can be captured in metrics. Those metrics can be nicely assembled within a single application, which gives a nice overview of the state of an application: Sonar.

Sonar (version 1.12 at the time of writing) is a web application that can be installed standalone or inside an existing Java Web Application Container, such as Tomcat. The standalone version is quite easy to install. Just download, start and a few moments later it’s ready on port 9000.

You can capture metrics using maven by running mvn sonar:sonar on your project. In some cases, your pom.xml file will need an explicit reference to this plugin, since it is not a default apache-maven plugin.

<build>
  <plugins>
    <plugin>
      <groupid>org.codehaus.mojo</groupid>
      <artifactid>sonar-maven-plugin</artifactid>
    </plugin>
  </plugins>
</build>

After running mvn sonar:sonar on your project, Sonar will contain metrics information of your application. Browsing to “localhost:9000” will show this.

Sonar has a nice overview screen that shows certain metrics (you can configure which ones you want to see) for all project. In a software development organization, this means that you have a single point where you can measure each project’s “technical health”. You could even add custom metrics, such as budget, number of people on the project, number of story points left in the backlog, etc.

Each project has a dashboard. The dashboard is an aggregation of more detailed metrics on a single page. This page gives a pretty good overview of the technical state of a project. When doing project reviews, this page is a good starting point to find items to investigate.

Almost every metric on the dashboard is clickable. When you click on a metric, you get more information about violating classes.

Configuring Metrics

Sonar uses findbugs, checkstyle and PMD to measure your code for bugs, ugly code and possible violation of code style policies. Sonar comes with a pretty good basic configuration, but the chance is big that you want to fiddle with the settings.

The easiest way is to take a basic configuration and make a copy of it. You can then change the configuration as you like. Note that you have to tell Sonar which projects should use this configuration.

Note that you must be logged in to be able to change the configuration. By default, there is one user, with username and password “admin”.

Another way to create a configuration is by specifically creating a new one. This is useful if you already have checkstyle, PMD and findbug configurations in your organization. You can then upload these files when creating your new configuration.

Sonar Database Configuration

The default configuration works nicely if you have Sonar installed locally and don’t mind to use the default Derby Database. For larger development environments, however, this default configuration is not enough.

You can configure Sonar to use a database quite easily. The “sonar.properties” file contains the basic Sonar configuration. Configuration examples are available for most databases. All you need to do is uncomment a block of configuration and make sure the URL, username and password are correct.

In maven, you have to configure the same URL’s. Personally, I find that a little awkward, since you need to share database details over multiple applications.

You can configure Sonar in your pom.xml file, which makes the configuration accessible to the projects using that pom. The following example configures a MySQL database.

<project>
  <properties>
    <sonar.jdbc.url>jdbc:mysql://my_sonar_db:3306/sonar?useUnicode=true&amp;characterEncoding=utf8</sonar.jdbc.url>
    <sonar.jdbc.driver>com.mysql.jdbc.Driver</sonar.jdbc.driver>
    <sonar.jdbc.username>sonar_user</sonar.jdbc.username>
    <sonar.jdbc.password>sonar_pass</sonar.jdbc.password>
    <sonar.host.url>http://my_sonar_url:9000</sonar.host.url>
  </properties>
</project>

Alternatively, you can pass all these parameters in the maven command line, or configure your maven settings.xml (on your build server, for example) to set these parameters.

Metrics don’t say it all

Although I believe that Sonar is a very nice tool to create code quality awareness, metrics don’t say it all. Some quality aspects simply cannot be caught in a metric. Just solving the issues that Sonar arises is not a good way to improve quality. Sonar can show problem area’s. It is up to the development team to find out where these problems come from, and solve them.

No matter how good the metrics are, each and every software project still needs a good process, a good project management, a hands-on architect and a smart development team to become a success.