Sonarqube: First steps and understanding the metrics

In this article, I’ll share my first knowledge about a code-quality tool, the Sonarqube.

Sonarqube is the tool for continuously inspecting the code-quality and guiding development teams during code-reviews. It’s compatible with 27 programming languages (include C# ❤) and contains a complete solution for include in your CI/CD pipeline.

For more and official information about this tool, view the Sonarqube official site. It has a Community version, I’ll demonstrate it in this article.

Running Sonarqube in Docker

For running Sonarqube, I use the official Docker image:

docker run -d --name sonar -p 9000:9000 sonarqube:latest

In this command, I execute the container and expose at port 9000. Accessing http://localhost:9000 and using the user and password admin/admin I already have the environment available.

To start, just create a new project, insert its name and token-name. As an example, I’ll run an open-source project that I have available on my Github, called web-app-clientes. This project is a .NET Core Web App.

After to create, and selected C# or VB.NET, the tool show the command-lines to running SonarScanner and send data to Sonarqube.

Installing SonarScanner and running the commands

Ok, I already have Sonarqube running, I need to install SonarScanner. It’s recommended as the default launcher to analyze project with Sonarqube.

Using .NET Core, to install the Scanner, simply run the command:

dotnet tool install --global dotnet-sonarscanner --version 4.8.0

Now, just run the commands indicated in Sonarqube itself, in the project directory. This command creates a .sonarqube folder:

dotnet sonarscanner begin /k:”web-app-clientes” /d:sonar.host.url=” http://localhost:9000 " /d:sonar.login=”token”

After, build the project:

dotnet build

Finally, run this command to send info to Sonarqube:

dotnet sonarscanner end /d:sonar.login=”token”

After completing the analysis, Sonarqube displays the project and its main metrics.

Understanding some metrics

Sonarqube has several metrics, as well as Quality gates, where it is possible to define a limit for each metric.

Code-smells

Is a surface indication that corresponds to a deeper problem. Usually not are bugs, they are not technically incorrect and do not prevent the program from functioning. However, they indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. In the project used, I found some code-smells:

• Remove this unnecessary ‘using’.
• Add a ‘protected’ constructor or the ‘static’ keyword to the class declaration.
• Add a nested comment explaining why this method is empty, throw a ‘NotSupportedException’ or complete the implementation.

Tip: For each code-smell in Sonarqube, just click on “Why is this issue” to understand it better.

Technical debit

Is basically an indicator of the cost of rework caused choosing a limited solution (usually the fastest 😊), rather than a higher quality solution. It’s the cost of correcting all code-smells in the code.

In Sonarqube, this indicator is for a period of time, considering that a working day has 8 hours.

Vilnerabilities and security hotspots

The main difference between a Security hotspot and a vulnerability is the verification if it is really necessary to make the correction.

• A Security hotspot highlights a security-sensitive piece of code that the developer needs to review. The overall application security may not be impacted.
• A vulnerability a problem that impacts the application security and need be fixed immediately.

Metrics are organized in Quality gates, where it’s possible define policies to assess the quality of the code. The Sonaqube e has a standard Quality gates, but it can be changed as needed.

Ps: Install plugins

On the internet, there are many plugins developed for Sonarqube (Ex.: Sonarplugins). To install any plugin from any source, it’s very simple. First, just access the container in bash mode:

docker exec -it CONTAINER_NAME bash

After, run this command to navigate to the plugin’s folder, and get the .jet file:

cd extensions/plugins/
wget plugin_jar_link

Once done, restart the container.

Bye!