OpenLMIS has its own SonarQube server and recommends that developers use the SonarLint IntelliJ plug-in as a comprehensive way to track and improve code quality over time. The Sonar configuration is aligned with the OpenLMIS OpenLMIS Coding Standards including the v3 Service Style Guide. In addition, Sonar also tracks test coverage and complexity, thereby serving as a tool to look broadly at code quality.

Using SonarQube

Start at the OpenLMIS SonarQube homepage:

The project links take you to the project overview showing specific issues tracked over time for that project (see below). The homepage also has a 'tree map' showing color-coded unit test coverage statistics. It allows you to click to drill in to find coverage gaps.

Project overview

The project overview page (i.e. this one for the OpenLMIS v3 Fulfillment service) show specific metrics and trends:

The 'Leak Period' shows how these statistics have changed in the last period, currently set to 14 days. That allows us to focus on what has gotten worse or better most recently, like over the course of a sprint. We can focus on fixing the issues as we introduce them. It is based on the Sonar philosophy of Fixing the Water Leak.

Clicking any of the links (on the bug count, code small count, etc) takes you to a specific list of the bugs/issues and shows where they happen in the source code. You can also catch these same issues in real time while code is written in IntelliJ using SonarLint (see below).

Project code view

Clicking on "Code" from any project view lets you drill in by folder to see any file of code.

Use this during code reviews to see if there are bugs in the code we are reviewing.

Code view indicates test coverage with color-coded green and red stripes. It also

The Test Coverage also displays orange stripes if some, but not all, of the conditions in branching logic are covered by tests:

Duplicated Code is specifically identified by line and file, even across projects (across repos):

Click on the red arrows to see details about any issue/bug:

Of course, there shouldn't be bugs in our new code, because any developer can see them right away using the SonarLint IntellIJ plug-in.

SonarLint in IntelliJ

The SonarLint IntelliJ plug-in allows you to see an easy report about code issues right inside IntelliJ. It runs an immediate analysis as you change code, and by 'binding' your plug-in with the OpenLMIS SonarQube server, it uses the same set of rules and checks.

Wow! Look at that immediate feedback!

How to Install SonarLint

Prerequisite: You must already have IntelliJ IDEA installed and have an OpenLMIS project open.

Launch IntelliJ and open an OpenLMIS project.
Download SonarLint plug-in from theSonarLint IntelliJ plug-in site. The download is a .zip file. Keep it zipped (you do not need to unzip it).
In IntelliJ, open Settings (called Preferences on Mac), then go to Plug-ins and click "Install plug-in from disk":
Select the plug-in zip file you downloaded. You may need to re-launch IntelliJ for the new plug-in to become active.
Set the SonarLint General Settings. You will need to add the connection to the OpenLMIS SonarQube server. Click the "+" button and fill in the dialog box that appears:

The Server URL is "http://sonar.openlmis.org". You do not need to change the default Authentication type and you do not need to enter a Token (leave the Token field empty). Use the "Test Connection" button to make sure your IntelliJ can connect to the OpenLMIS Sonar.
Set the SonarLint Project Settings:

Click "Enable binding...", then select the OpenLMIS server you added in the previous step. Then select the project that corresponds to whichever project you have open in IntelliJ.
That's it! Now you can use the SonarLint feature inside IntelliJ to get immediate feedback.
The Project Settings are made per IntelliJ project, so you will need to open each OpenLMIS project you are working on and set the project settings for each one. Each one connects that IntelliJ project to the matching project in SonarQube.

Ways to Use Sonar

There are three main use cases for Sonar that we are encouraging during the OpenLMIS v3 development:

1) SonarLint plug-in in IntelliJ. We encourage all developers to use it. We want to clean up code as we touch it (fix as we go).
2) During Reviews: Open Sonar to look at errors and issues in the code during a review. Also look at test coverage to consider whether the new code has enough tests. Bring up issues in the Fisheye review process.
3) Periodically Triage: The teams map pull up Sonar periodically to look at our most common issues and to look at broader trends in test coverage. We can use this to guide our discussions about what to prioritize as we work towards improved test coverage and quality.

False Positives

Sometimes SonarQube and SonarLint will show errors or issues that are not really a problem. A good time to discuss this is the code review process. If peers agree that something isn't really a bug, we can leave it coded that way.

Although Sonar metrics are aligned with OpenLMIS coding standards, you may disagree with the filters and metrics that Sonar is using. If so, it's worth bringing that up for team discussion. There may be rules we want to adjust or change. It is possible for us to adjust the rulesets and change our coding standards, but only after significant consideration. There is also good reason to stick with the industry-standard rules and best practices.