Code quality is a very important measure of a developer’s work. To make it inspectable, our team applies a static analyser and quality management platform called SonarQube. Thanks to its features we can find out where our code should be improved and refactored, and also a lot of bugs can be detected before runtime. Although SonarQube provides exact numeric metrics about quality, reviewing and comparing them is not always easy and obvious if we want to spot salient values in huge software systems.
Visualizing the code is a practical way to solve this problem. It also makes the metrics more perspicuous thus much easier to understand. The CodeMetropolis project, which is developed by the University of Szeged, is an open-source visualization tool based on Minecraft. We modified and configured it to serve our demands properly and get a simpler and cleaner view of our projects. Our modification will be contributed to the repository of the project, so it will be easily accessible.
This tool makes SonarQube analysis data tourable as a big metropolis and because of the huge project size it is divided into cities along component borders. A city contains gardens and there are buildings in each garden. Here, using our own mapping a garden means one package, and a floor means one class.
The most important metrics for us to visualize are the number of critical violations and duplications, so these are by far the most emphasized properties of the generated cities. In the metropolis the color of the external walls changes in accordance with the number of violations (within a class) and the color of the windows changes in accordance with the number of duplicated lines. As the value increases their color transforms to yellow, orange and finally red in case of relatively high values.
Test coverage of a package can be seen as the flower ratio of a garden (larger ratio means better coverage). Class complexity is a major metric too which is now represented by the width of a floor. We expect that most violations will take place in relatively complex classes.
As you can see it has become easy to spot messy pieces of code and compare them even in case of huge projects.
We have also created an overview map for the entire project. However, because of the project size another mapping is being used: here a garden represents a project and a building floor represents a package.
As demonstrated above the blocker violations, being by far the most serious issues (red, glowing grass in a garden), are eye-catching and at that point changes are definitely needed in the source. It is easy to locate the problems by checking the package and class name on the signposts.
By using this visualization tool the most important weaknesses in quality are easily noticeable. The metropolis can be generated automatically from time to time and everyone in the team can reach the latest cities of the actual components. Hopefully this visualization will motivate everyone of us to improve, learn and write as clean code as possible.
Written by Krisztian Mozsi