You probably never heard about “Code Cancer”, but this term would be an adequate description for some key issues most non-trivial software systems are suffering from. Chances are that your own organization is affected by it right now. In this article I will describe what I mean by “Code Cancer” and offer ideas how to mitigate this problem.
Read MoreUsing Sonargraph-Enterprise to Track Key Quality Metrics
Sonargraph-Enterprise is designed to allow stake-holders to track important software quality metrics over time. The idea is that this would enable the early detection of harmful trends so that issues can be fixed while they are still easy to fix. The metrics displayed by Sonargraph-Enterprise can be fully customized by the user. However, in this article I will explain the “default” profile that comes with a set of preselected metrics that cover important aspects of code health and quality.
Read MoreSetting up Sonargraph on your Project
Over the years we implemented many different methods to set up Sonargraph for your project. Some of them are now quite outdated and are only kept in the tool for compatibility reasons. This article is meant to help you with your initial setup and chose the most effective method for your particular circumstances. There is one section for each language supported by Sonargraph.
General Recommendations
Sonargraph maintains a folder for each software system, that contains a description of your project, the locations of source folders (and class folders for Java), your architecture model and all other parts of a Sonargraph quality model. We call this folder the Sonargraph system folder. It only contains text files (mostly XML) and should ideally be placed in the root directory of your VCS (version control system) repository. You also should add this folder to your VCS, since the Sonargraph model will evolve together with your software system. This will allow you to share one Sonargraph model with all the developers working on your project.
Each Sonargraph software system contains at least one module. Modules usually correspond to the modules or sub-projects in your IDE.
How to initially create this folder for your project is the subject of this article. The folder should have the name of your software system and always ends with ‘.sonargraph’.
Read MoreUsing ccspy for C/C++ Project Setup
Analyzing C/C++ projects with Sonargraph is always a bit more difficult due to the huge variety of different compilers and environments. We recently added a new import wizard that should simplify the process.
For a successful analysis of a C/C++ projects Sonargraph must be able to emulate the compiler you are using and also needs to know which source files are part of the project and the compiler options used for each source file, mostly the -I
options for include directories and the -D
options which influence conditional compilation.
The first part is solved by a so called “compiler definition”. Sonargraph comes with predefined compiler definitions depending on your platform. If your compiler is not among them you can always create a new compiler definition (menu File / New / Configuration). You can also manage your compiler definitions in the Sonargraph preferences. The main job of a compiler definition is to define the location of implicit include directories (for standard headers like stdio.h
) and to define all predefined macros of your compiler platform.
Discovering Software Rot
Since I have seen some announcements about talks targeting the German Corona Warn App, I was interested to see, what kind of information I could extract with Sonargraph.
The project is still pretty young, but maybe, there is already some structural erosion happening? (Spoiler: There is!)
This blog post is about the setup of the analysis-pipeline consisting of Sonargraph-Build and Sonargraph-Enterprise that allowed me to analyse 24 versions (1.4.0 to 2.9.0) of the CWA-Server project and investigate metric trends.
The execution is implemented in Java and published as a new repo “Sonargraph-Build Batch“. If anybody is interested in analyzing past versions of a project with Sonargraph, “Sonargraph-Build Batch” can serve as a starting point.
Read MoreNew Features in Sonargraph 12
Sonargraph 12 is out! This release contains a couple of major changes: A reworked Exploration view, a refactored System view (dashboard) with new metrics and visualizations, faster C/C++ parsing and various other improvements.
Read MoreRecently Added Usability Improvements
During the last months we released a couple of major features in Sonargraph that allowed easier interaction like the ‘Architectural View’ and improved the interpretation of results like the ‘System Diff’, ‘Quality Gates’ or ‘Issue Ranking’. We have described the power of these features in individual blog posts.
Some implemented improvements are less obvious, but nevertheless can have a big impact while working with Sonargraph.
This blog post highlights four hidden gems that the casual Sonargraph user might not know about:
- Improved issue to resolution matching
- Filtering in tables
- Visualizing cycle croups in Exploration view
- Passing selection between Sonargraph and Eclipse IDE
Identify the Most Relevant Issues to Fix
Using Sonargraph to analyse a large code base usually reveals a lot of issues. The “System Diff” helps to keep the quality level by highlighting new and worsened issues as described in a previous blog post. But up to now there has been no recommendation about which of the already existing issues should be fixed first.
The new “Ranking” view available in Sonargraph 11.5 does exactly that and this blog post describes how it works.
Motivation for Code Quality
The main idea behind Sonargraph has always been to provide a tool that eases the creation and maintenance of high-quality software. For any serious project that must live longer than a couple of months, it is actually cheaper to spend a part of your resources to keep your software constantly at a good level of quality than using all your time to create new features. Martin Fowler explains this very well in his article “Is High Quality Worth the Cost?”. The bottom line is, that apart from the very early development stages, high-quality software is actually cheaper to develop, because it allows adding new features at almost constant speed, whereas it becomes more and more time consuming to add new features into a code base with low quality. According to our experience the most successful teams spend about 15% to 20% of their time on code hygiene.
We at hello2morrow believe that a consistent architecture is a fundamental part of software quality. When we use the term “architecture”, we think of it in terms of the IEEE 1471 standard:
“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”
This blog post describes why architectural design as an activity is needed, why conformance checks need to be done automatically by a tool and how Sonargraph supports you as a developer and architect during these activities.
Read MoreEfficiently Track the Quality of a Code Base
Sonargraph offers a wide range of checks for different aspects of software quality: Architecture, metric thresholds, cyclic dependencies, duplicate code, etc.
When Sonargraph gets introduced for software projects that have been developed a couple of years, chances are high that hundred’s of issues are reported. But getting flooded with issues and sifting through them at regular intervals is neither efficient nor really helpful. Instead, you want to get a quick overview whether or not the quality is going into the right direction.
And this is where quality gates come into the game: they allow focussing on the information important to you.
This blog post details how this functionality is implemented in Sonargraph.
Read More