The C/C++ plugin combines the power of SonarQube, Clang and CppDepend. It allows users to benefit from the reliability of the Clang when parsing the code, the features from CppDepend to create easily coding best practices rules using CQLinq and the richness of the sonar platform. Getting started with C/C++ SonarQube Plugin.
There are many ways to measure a code base. The most common way is to count the number of lines of code. This metric gives a rough estimation of the effort that had been put in to develop the code base. It also allows you to obtain a quality level agreement by pinpointing fat methods and classes.
The plugin counts the number of lines of code. It also comes with other standard code metrics. Some of them are related to your code organization (the number of classes or namespaces, the number of methods declared in a class...), some of them are related to code quality (complexity, percentage of comments, issues,...).
The DSM (Dependency Structure Matrix) is a compact way to represent and navigate across dependencies between components.
CppDepend detect all the dependencies between projects, namespaces, classes and methods. These dependencies could be navigated from the Visual CppDepend.
The DSM provided by SonarQube show the dependencies at the file level, and we can easily detect the dependencies weight between directories, files and their dependency cycles.
This view is very useful to improve the design of your projects, and detect the dependencies to cut.
Adding additional, unnecessary code to a codebase increases the amount of work required to extend and maintain the software in the future. Duplicate code adds to technical debt. Whether the duplication decreases the quality of the code.
The CPD which is a powerful tool to detect duplications is used to calculate some useful metrice about duplications.
The idea behind this graph is that the more a code element of a program is popular, the more it should be abstract. Or in other words, avoid depending too much directly on implementations, depend on abstractions instead. By popular code element I mean a project (but the idea works also for packages and types) that is massively used by other projects of the program.
It is not a good idea to have concrete types very popular in your code base. This provokes some Zones of Pains in your program, where changing the implementations can potentially affect a large portion of the program. And implementations are known to evolve more often than abstractions.
The main sequence line (dotted) in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line – on the other hand, if its degree of abstraction is low, it is positioned in an area that is called the “zone of pain”.
The C/C++ plugin combines the power of SonarQube, Clang and CppDepend. It allows users to benefit from the reliability of the Clang when parsing the code, the features from CppDepend to create easily coding best practices rules using CQLinq and the richness of the SonarQube platform.