Most of you would already know about SonarQube, and most of you will already be using it. I never got the opportunity to use it, even though I had heard about it. But recently, I decided to make it a part of my development pipeline for my personal projects. So I set it up as a Docker service on my laptop and installed the SonarLint IntelliJ IDEA plugin. And the analysis results shocked me.

In this post, I’ll talk about what SonarQube is, how to install it, and how to use it. Hopefully, by the end of this post, I will convince you enough to include it in your pipeline. So let’s get started.

What is SonarQube

I’m going to shamelessly plug the Wikipedia definition for the tool:

SonarQube is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities on 20+ programming languages. SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities.

SonarQube can record metrics history and provides evolution graphs. SonarQube provides fully automated analysis and integration with Maven, Ant, Gradle, MSBuild and continuous integration tools (Atlassian Bamboo, Jenkins, Hudson, etc.).

That pretty much explains what SonarQube. But if you’re still unclear, let me put it simply. SonarQube is a tool that checks your code for code quality, best practices, bugs, security issues, duplicate code, code coverage, and much more. The best part is, you can integrate it to your CI/CD pipeline. And this makes sure your whole team is following all the best practices for your tech stack.

I’ll show you a few screenshots of the tool and the analysis it gives to give you a better idea. But first, let’s see how we can install it.

Installing SonarQube

There are many licencing options available on the tool’s website. You can look at it on the download SonarQube page. I went with the community edition, by the way. Also, if you don’t want to install SonarQube directly on your machine, you can run in a container using Docker. The people over at SonarQube have been cool enough publish a Docker image to run SonarQube. It is similar to any other Docker image you’d run using a Dockerfile. You can find the Dockerfile over at Dockerhub.

If you download the distributable package instead of the Dockerfile, unzip it to a directory of your choice. cd into the directory, and execute the following command to start the SonarQube server:

./bin/linux-x86-64/sonar.sh start

You should see a success message saying that SonarQube is now running. That’s it. You have installed the SonarQube server. Now let’s get into it and create a project.

Creating a project in SonarQube

Once you start the server, head over to http://localhost:9090 to login to the SonarQube webapp. Use the default username and password (admin/admin) to login. Here, create a project which reflects your actual project. The screenshot below represents this step:

In the next step, provide a name for the token. You will use this token to associate the results of code analysis to this project. Once you provide a name, SonarQube will generate a new token for the project. The screenshot below represents this step:

Click the Continue button to move to the next step. In the next step, select the programming language you used in your project. If you remember from the definition, SonarQube supports 20+ programming languages. So there is very little chance that it doesn’t support your programming language. For my example, I have selected Java.

Next, depending on your project, select the build tool. For Java, it’s either Maven or Gradle. In my case, it’s Gradle. The screenshot below summarises this step.

As you can see from the screenshot, SonarQube even provides the command you need to run to analyse your code. If you select Maven, you’ll get the Maven-specific command. You can just copy-paste this command to your terminal and run it.

In the next section, we’ll see how the dashboard of the project looks.

Code Analysis Results

After running command we got in the previous step, the results of the analysis will be pushed to the SonarQube server. In our case, it is running locally. The dashboard, or the project overview, looks like the screenshot below:

As you can see, there’s a lot of data here. And as you could imagine, I spent a good amount of time to get the results to this level. Now, we’ll talk about the different sections of the overview, one by one.

Bugs

The first section in the overview is Bugs. Suppose you open a file in your code using a FileReader. But you forget to close the file. This is a bug and will be flagged by SonarQube in this section. You can click on it and go to the list, where all the bugs will be listed. You’ll find this list in the Issues tab.

You can go through all the bugs here and assign each one to a different member of your team. Also, you can set the severity of the bug, there are various built-in levels.

Security

The next section is security. As the name suggests, this lists all security issues in your code. For example, in one of my products, I have a security hotspot. When I go to the Issues tab and list all the security hotspots, this is what I see:

As you can see from the screenshot, the analysis is pretty thorough. The status for this right now is To Review. I can change that to something like Resolved or In Review.

Code Smells

In this section, you’ll see issues created for duplicate codes, unused variables and methods, test classes without any tests, unused imports, and the like. This comes in very handy when you want to remove unwanted code blocks from your code to keep it clean, mean, and maintainable. Unused code can cause confusion for a new programmer who is seeing the code for the first time. So make sure you have the least possible, if not zero, code smells in your project.

Also, because SonarQube flags duplicate code, it becomes easy to find such code and refactor it in a meaningful way. And, it also leads to better design as you can take common properties from various classes and make that into a base class.

Coverage

As the name suggests, this section shows you how much of your codebase is covered with unit and integration tests. I don’t think I have to talk about how important code coverage is. But getting this information along with all other metrics is very useful.

There is one thing to note here though. You need to use dedicated plugins for both Maven and Gradle to get coverage reports in SonarQube. It doesn’t use any pre-generated XML or HTML files for this. But the best part is, it is pretty easy to integrate.

Duplications

The last section on the overview page is duplications. This is simply, code duplication. The second section, which is code smell, already covers code duplication. But there is a dedicated section for it anyway. You can expect to see the same code duplication report here that you would see in the Maintainability section.

So, I hope that was useful. Ever since I started using this tool, I have found it very useful. I keep analysing my code for each change I make. I am able to reduce a lot of code smell while writing the code itself, thanks to the SonarLint plugin for IntelliJ IDEA. I installed the plugin and connected it to my local SonarQube server. This way, as and when I’m writing the code, the plugin analyses my code and gives me warnings in the IDE itself.

I highly recommend this tool for you as an individual, and for you as a team. You have to use it to believe it. I’m by no means promoting SonarQube or using any affiliate link here. If not SonarQube, use some other code analysis tool. But I think it is important to use a tool like this during the development of a project to keep the code clean.

And if you like what you see here, or on my Medium blog, and would like to see more of such helpful technical posts in the future, consider supporting me on Patreon and Github.