Code visualisation with CodeCharta

In audits and reorganization projects, it is important to promote the exchange between developers and project managers or product owners. At MaibornWolff, we like to use a city metaphor to visualize code. The CodeCharta tool developed by us and released as open source visualizes code in exactly this way. I present it below using an example.

CodeCharta makes implicit structures in the code visible. Like the old software maps, it shows the complexity of classes, code coverage, change frequency and much more. In our software city, we see changes in comparison with older maps, recognize focal points and can derive measures for refactoring. Compared to the old software maps CodeCharta is more focused on the needs of audits and projects, but at the same time more extensible and better customizable to the respective project. CodeCharta does not reinvent the wheel and uses tools such as SonarQube and SourceMonitor to obtain metrics data on the code. It therefore speaks all languages that these tools also speak, including C, C++, C# and Java. CodeCharta consists of two parts: Analysis part, with importers for these tools, and visualization engine, which runs as desktop or online version downloadable from Github.

I'll show you how to work with CodeCharta using an example. I have picked out the Apache Tomcat code for this. First, we use the public SonarQube server on sonarqube.com to analyze the Apache Tomcat code. From GitHub I downloaded the latest version of CodeCharta, in my case version 1.1.3, and installed it as described on the project page . I then used the command ./ccsh sonarimport https://sonarqube.com/ org.apache:tomcat > apache_tomcat.json to create a json file with the visualization data for Apache Tomcat. I now load this into the online demo (or the standalone version) of CodeCharta. I can already see a city with many, many buildings:

The buildings represent files with classes, which are divided into blocks based on their file hierarchy. The area, height and colour of the buildings correspond to metrics from visualisation data.

To get an impression of the size of Tomcat's source code, we change the mapping of the buildings: under Metrics, we select ncloc as the metric for area, height and colour. In addition, under Colour Settings, we set the limits for the neutral colour to 500 (start) and 2000 (end). The result looks like this:

When you look at the image of this city, you immediately notice that almost half of the code lines are in large classes, and that classes such as StandardContext have over 2000 lines of code. ‘Why does the context in Apache Tomcat have so many lines?’ you might ask yourself. You could ask the developers for the answers or look them up in the code.

Since I don't have the developers at hand, I do the latter and see a class that implements two interfaces, extends a class, contains more than 100 non-inherited fields and several complex methods – in short, a god class. Definitely difficult to maintain, test and further develop; but then again, who would have expected anything else from a ‘standard context’?

Next, we will look at another map, an overview of complexity. Since SonarQube only provides the average and aggregated complexity, but the maximum complexity of the methods contained is more meaningful for hotspot analysis, we will use SourceMonitor and the SourceMonitorImporter from CodeCharta this time. To do this, we first install SourceMonitor v3.5 in “C:Program Files (x86)SourceMonitor” (...yes, unfortunately this tool is only available for Windows).

Then we download the Apache Tomcat sources from GitHub. In the bin directory of SourceMonitorImporter, we run the command ./sourcemonImport.bat tomcat ~/Projects/github/tomcat/java/ java > apache_tomcat_sourcemonitor.json and obtain further visualisation data. Since SourceMonitor has a small bug when calculating complexities for some files, we delete the entries for the complexity of the file NonBlockingCoordinator.java in the created apachetomcatsourcemonitor.json. We now also load the result into CodeCharta. This time, we set the mapping of the buildings under Metrics to ‘Statements’ for the area, ‘Maximum Complexity’ for the height and colour, and in the Colour Settings we select 50 and 100 for the colour limits.

In this map, the file Request.java in the package org.apache.catalina.connector stands out in particular, which has a function with a complexity of over 300 and, with over 1000 statements, is not exactly small either. The class contains a lot of fairly complex code, at least some of which could have been moved to specialised classes. Overall, however, the number of complex classes is kept within limits.

It gets really interesting when you add data from Git, such as the frequency of changes. This allows us to answer whether that part of the code is still in active development and whether it is worth carrying out refactoring measures there.

CodeCharta can also be used to make statements about code coverage, which can be helpful when it comes to questions about the risk and effort involved in refactoring measures. But that's a story for the next blog article.