Code quality is often said to be an internal attribute of quality, since the user never lays eyes on it. But, there comes a time when this attribute of quality goes from being internal to external, which happens precisely when the code must be changed, yet it takes much longer than it should and so, the user suffers while they wait.
In order to guarantee correct code quality, you can use different static code analysis tools, such as SonarQube, Codacy, Kiuwan, etc. Among the checks on code quality that they carry out are:
- Duplicate code
- Lack of unit tests, lack of comments
- Spaghetti code, cyclomatic complexity, high coupling
- Size of source files
- Size of methods
- Not conforming to code standards and conventions
- Known security vulnerabilities
These tools allow for automatic static analysis of source code, looking for patterns with errors, bad practices or incidents. In addition, many of them are capable of calculating a metric known as “technical debt.”
What is Technical debt?
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the “technical debt” metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.[4][5]
As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. Required changes that are not completed are considered debt that must be paid at some point in the future. Just like financial debt, these uncompleted changes incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.
In the particular case of SonarQube, by defining “quality gates” it is possible to mark acceptable thresholds in the development process, which can be determined based on different metrics. The quality gates definition can also help answer questions such as:
- Are there are any new issues that are critical or blocking?
- Is the code coverage of unit tests for the new code greater than 80%?
- Are there more than 10% duplicate lines?
- Are there any known security vulnerabilities?
You can start by setting flexible thresholds (quality gates), and throughout the project, try to set more stringent targets. For example, you could start by demanding 100% coverage of public methods, and then increase to have 100% of the lines of code.
It’s important to emphasize that coverage at the code level does not guarantee that the software is bug-free, not even the most demanding one. Sometimes it doesn’t make sense to propose a 100% coverage of the lines of code. This is due to, more than anything, that some code could be generated automatically by a component or tool, and also, because not all modules of the system will have the same criticality. In this sense, it’s possible to define different quality gates for different modules. You can also adjust the rules on which the static analysis is based.
In order to verify the internal quality of a system, one typically performs code analysis with SonarQube or a similar tool.
In order to use SonarQube you need to install a server component, where the engine that performs the analysis and stores the results is located, and the analysis must be invoked in some way, which can be done with a client called SonarQube Scanner or with a Maven plug-in. You can also integrate the analysis with the IDE that you are using, with a plugin called SonarLint. In this post, you’ll see how to install the server (using a Docker image) and how to invoke the analysis using SonarQube Scanner.
Setup
Lets start run the sonarqube in docker, with some specific port. Here we have named the container and also add port 9092.
docker run -d –name sonarqube -p 9000:9000 -p 9092:9092 sonarqube
By default you can login as admin with password admin
If you are using any DB, use can create the user and link with sonerqube, even in you can add which starting a container also, For that use;
docker run -d --name sonarqube \ -p 9000:9000 -p 9092:9092 \ -e SONARQUBE_JDBC_USERNAME=sonar \ -e SONARQUBE_JDBC_PASSWORD=sonar \ -e SONARQUBE_JDBC_URL=jdbc:postgresql://localhost/sonar \ sonarqube
To verify the installation, try to access http:// docker-Host-IP: 9000. Hope you can see the screen like below
Now you can login using default username and password, admin/admin. Once login successfully, it will ask token which you can use for authentication.
Then you can select the environment and OS details, once you have added, you need to install sonarqube scanner to run the scan.
Note: In this form, define the name that the project will have on the server, the version and the project key (which may contain letters, numbers, ‘-‘, ‘_’, ‘.’ And ‘:’, and at least one digit).
You can download sonarqube scanner on Scanner URL.
Once you downloaded, you can unzip it. Then got sonar-scanner directory/bin.
Here you can run follow command to start the analysis, (this command you get while add the scan details)
./sonar-scanner -Dsonar.projectKey=<<-projectname->> -Dsonar.sources=. -sonar.host.url=http://hostIP:9000 -Dsonar.login=token
Once scan done, it will give the result with URL, there you can see the analysis details report. above added the sample one.
Running the Analysis with Maven
To begin with this process, the first thing you must do is add the SonarQube plugin to your Maven project as follows:
<pluginManagement>
<plugin>
<plugin>
<groupId>com.foxutech.test</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.7.1</version>
</plugin>
::::::
</plugin>
</pluginManagement>
Once you add the sonarqube plugin, it will do complete code analysis from maven, it will connect with you docker sonarqube which we just installed for that you have to mention the sonarqube server IP.
Then, all that remains is to go to the directory of your project and execute the Maven goal with the following command:
mvn sonar:sonar -Dsonar.host.url=http://docker-host:port
The name of the project in SonarQube and the version is taken from the Maven project (at the beginning of the pom file).
Running the Analysis in an IDE
This other method will allow you to execute the analysis directly from the IDE of your preference. Particularly here we will show you the use of the SonarLint plugin for IntelliJ, but it’s equivalent for other development environments such as Eclipse or Visual Studio.
