Sonar 1.9 has just been released : installing this new version implies to be aware a few things. I’m not talking here about any technical complexity to upgrade from previous releases but about functional evolutions.

So far, the standard metrics (number of classes, number of comments, cyclomatic complexity…) were gathered using the well known JavaNCSS. However, as mentioned in a previous post, the metrics calculated by the current version of JavaNCSS has some flaws (creating new metrics is pretty difficult, comments are not available at class level), suffers approximations (nested classes are not managed) and crashes on certain code patterns (annotations, generics, none UTF8 characters). Therefore we have decided to proceed with a complete rewrite of JavaNCSS that we named sonar-squid.

The rewrite significantly improves several quality axes and makes Sonar even more unique :

Sizing the project
So far, the only measure to size a project was the Non Commenting Source Statements. From Sonar 1.9, there are going to be four of them :

• Lines : the number of carriage returns
• Comment Lines : the number of not blank comment lines – License Header Lines
• Lines of code : Lines – Comment Lines – Blank Lines
• Statements : as per Java Language Specification (excluding method body definition)

Not only are those new metrics essential to get a true view on a project size, but it enables to keep consistency throughout metrics. For instance, the density of duplicated lines can now be based on the number of physical Lines, the density of Comment Lines on the number of Lines of code, code coverage on the number of statements…

Moreover, there’s a new graph displaying the distribution of methods according to their complexity along with the old graph displaying the distribution of classes complexity.

Methods
We have made a deliberate choice to separate methods from “pure” accessors (getters and setters), the latest being technical and language dependent while the first ones contain the functional logic. Therefore when discussing methods, we have chosen to select only real methods, excluding the ones that have no business value and have certainly been generated automatically by your IDE.

To be consistent, “pure” accessors don’t increment the cyclomatic complexity value, that means “pure” javabeans have now a cyclomatic complexity of 0. Sounds like an evidence as they don’t contain any logic, doesn’t it ?

This new behavior will increase (maybe strongly) the average complexity by method in your project and probably reduce the classes one. Although we think this a major step toward code quality management (better accuracy of the measures), we kept the possibility to unplug the separation between methods and accessors. This is done through a parameter in the configuration menu.

Comments
At last… comments are going to be analyzed properly in Sonar : files headers (licenses) and blank lines are now ignored. Further more, the Comments widget now displays the density of commented (Javadoc) public API. By public API, we mean public classes, public methods (excluding acessors) and public fields. Apache Felix iPOJO project has for instance 90.7% of documented API which is very good. All those comment related metrics are now available at class level.

So, where is the problem ?
Although all this sounds very good, there is a drawback : your historical data is going to be shaken. Indeed, because measures are calculated differently, it is not going to make sense to compare them throughout time, except if you decide to override historical data by running Sonar on previous versions of your application.

A complete description of all metrics can be found in the Sonar wiki. Want to give a try to Sonar 1.9 and play with these new metrics ? You can download it here…