Exploring SonarQube concepts

Posted by Maarten De Raedemaeker on 2017-07-23
Software development

The goal of this post is to dive into SonarQube concepts using a practical approach.
We’ll start from the following source code, after this tutorial we’ll end up at this stage.

Table of contents


As a guide for exploring the SonarQube concepts, I’ve added an overview image below.


Quality profiles

A quality profile contains a set of rules used to generate issues for a snaphot when a new analysis is submitted to the server.

By default, one quality profile “Sonar way” is provided for each language we use.
It is recommended to copy the profile for our project and tweak it to our needs.
To do this, we need to visit the dashboard and navigate to each of the quality profiles.


After choosing a new name for our quality profile, we need to assign it to be used in our project.


You’ll notice that the quality profiles will still show as “Sonar way”. When we run the analyzer again, it gets updated.


After copying all of the profiles, we’ll take a look at how rules are used in the profile.


The goal of rules is to detect issues.
There are a nice set of predefined sets, you’re also able to create steps with custom rules using templates or even write your own Roslyn analyzer.
Let’s take a look at a predefined example.


This rule is enabled by default in the “vulnerabilities” section. It does not allow public static fields which are mutable.

To demonstrate SonarQube rules, I’ve added a file to my project with several issues in it. You can take a look here.

As you can see in the image below, my project is not scoring well at all. SonarQube has detected a bunch of issues.


I can navigate to the file I’ve added and zoom in on the specific issues by going to the code tab and navigating through my code structure.

SonarQube also makes a list of issues with an estimated “time needed to fix”, which is summed to the total number as show in this image .


A metric is something that can be measured.
As the documentation points out, they can either by a qualitative or quantitative metric.
Quantitative metrics, like for example number of line of counts do not give quality indications.
Qualitative metrics, on the other hand, do say something about quality. Their measures impact scores such as reliability, security and maintainability.


Measures are values for specific metrics. They can vary over time, and contained within a snapshot.


If a violation on a rule is found, issues are added to the snapshot.

3 kinds of issues exist:

  • Bugs could be potential points of failure in your code.
    For example:
    Also note the nice way of documenting the rule, complete with instructive examples.

  • Code smells are issues that have maintainability impact.
    For example:

  • Vulnerabilities are security related issues.
    For example


A snapshot is generated when we execute and submit a scan.
They have a set of measures containing values for metrics and a list of issues generated by rules;

Quality gates

A quality gate is a group of requirements that needs to be met to achieve “enough” quality for a given snapshot to be release-ready.
By default SonarQube provides one.


For more information: take a look at the SonarQube documentation

SonarQube documentation: concepts