Use SonarQube + Sonargraph Plugin to Detect Cyclic Dependencies

Cyclic dependencies have long been seen as a major code smell. We like to point to John Lakos as a reference [Lako1996], and a Google search about this topic will bring up valuable resources if you are unfamiliar with the negative effects. In this blog post, I take it as a given that you are interested in detecting cycles and that you agree that they should be avoided. If you see things differently, that’s fine by me – but then this blog post won’t be really interesting for you.

A number of static analysis tools exist that can detect those cycles in your code base automatically. SonarQube was one of them, until the Dependency Structure Matrix (DSM) and cycle detection was dropped with version 5.2. The DZone article by Patroklos Papapetrou (“Working with Dependencies to Eliminate Unwanted Cycles”) and the SonarQube documentation (“Cycles – Dependency Structure Matrix”) illustrate the previous functionality.

I noted that some people are missing those features badly and complain about their removal. The comments of the issue “Drop the Design related services and metrics” and the tweet of Oliver Gierke are two examples.

But thanks to the SonarQube ecosystem of plugins, there is a solution: Use the free Sonargraph Explorer and the Sonargraph Integration Plugin to get the checks for cycles back in SonarQube!
I will demonstrate that the setup and integration of Sonargraph into the build is fast and easy.


Automate Cross-Project Analysis

Sonargraph is our tool to quickly assess the quality of a project. I get frequently asked, how Sonargraph supports the Enterprise Architect who needs to answer quality-related questions in the broader context across several projects.
Since we recently released new functionality that allows the automation of re-occurring quality checks, it is now the right time to write a blog post.
Example questions that an enterprise architect wants to answer:

  1. How frequently does a certain anti-pattern occur?
  2. How strong is the dependency on deprecated functionality?
  3. How many of my projects suffer from high coupling?

This article will demonstrate the following core functionality of Sonargraph to answer the above questions for a couple of projects and how to automate this analysis.

  1. Use a script to detect an anti-pattern (“Supertype uses Subtype”)
  2. Create a simple reference architecture to detect usage of sun.misc.Unsafe
  3. Add a threshold for a coupling metric (NCCD)
  4. Export a quality model
  5. Use Sonargraph Build Maven integration to execute the analysis.
  6. Create a small Java project to execute the Sonargraph Maven goal, access the data in the generated XML reports and create a summary.


Dead Code Detection

Research [Strei2014] and other sources (e.g. [Pizz2013]) have shown that typical software code bases contain 5-10% “dead code”, i.e. code that can be removed without reducing the functionality.
Streamlining the code base by identifying and removing dead code has several benefits:

  • Less maintenance cost: Whilst dead code is less likely to be changed frequently, it still has to be understood and might be effected by refactorings.
  • Smaller footprint: Less code makes the development environment faster, the build and deployment processes are more efficient, and the size of runtime artifacts are smaller.
  • Better precision for calculated metrics: Dead code contributes to software metrics, e.g. “average test coverage” might be improved by tests for unused code and therefore creating false confidence.

Dead code grows in projects for the following reasons:

  • Only few developers check in their IDE if some element is still in use, when they remove a reference to it.
  • Identifying reliably that a public class or method is “dead code” is not a trivial task and requires deep knowledge about the code base.
  • Removing seemingly dead code can easily lead to new bugs therefore developers are usually reluctant to remove them.

It is likely that more dead code exists in large and long running projects with a high fluctuation of developers.

Detecting dead code is a good use case to illustrate Sonargraph Explorer’s powerful scripting API and to demonstrate how it can be used to efficiently detect dead code within a Java project including public classes, methods and fields.