SonarQube (SQ) is a static analysis tool aimed at performing automated code reviews based on static code analysis, and supporting expert reviewers in manual reviews.

The GN WP9 T2 team maintains an instance of SQ available at https://sonarqube.software.geant.org and offers software development teams in GÉANT a variety of services based on SonarQube capabilities.

In the cover folder Software Reviews we describe the types of reviews offered by the WP9 T2 team.

A number of manuals describing typical SQ use cases (such as the procedure for entering a development project into SQ) is described here.

In this document, we briefly provide an overview of capabilities and functions provided by SonarQube, that could be used by code reviewers (subject-matter experts, SMEs) in performing the reviews requested by software development teams.

Introduction

SQ analyzes the software projects with respect to five main quality characteristics and their corresponding flaws:

• reliability (bugs)
• security (vulnerabilities)
• maintainability (code smells)
• code coverage
• duplications

Each type of the flaw is reported separately and can be analyzed in a different way.

Navigating in SQ

Overview screen

After selecting a project, SQ presents a screen with an Overview screen, which provides the core data for each characteristic. These are:

• bugs, vulnerabilities, and security hotspots
• code smells
• coverage
• duplications

For each of these, SQ reports the number of flaws, a rating (from A to E, with A being the highest / "best" score) for this characteristic, and a link to a trend diagram. Each of the reported information can be clicked and directs the user to more detailed analysis and/or diagrams for this value. The definition of the ratings as provided by SQ is described in the Rating table below (as well as, in more detail, at the official SQ documentation).

SQ reports separately the overall numbers and the values for new code (i.e., for the code developed since previous analysis in SQ). That helps in getting the general insight into the project status, and tracking the trends.

On the right-hand side, SQ presents the log of its analysis and a small diagram showing all relevant trends in all analyzed versions of the  subject project.

Issues screen

More detailed information is provided by the Issues screen. It presents the list of all issues discovered by SQ, either in the past or currently. On the left-hand side, there are various filters that help in managing the scope of presented issues. Filtering options include the type of issue, its severity, resolution, current status and other information. Please note that the filters are cumulative, i.e., they produce a conjunction of all imposed filters.

Issues presented on the list can be processed by the reviewer, subject to permissions granted to them. By default, reviewers should be able to update the following attributes of the issue:

• type: Bug, Vulnerability, Code Smell (although it is not recommended to alter this value)
• severity: Blocker, Critical, Major, Minor, Info; please note that changes in severity may affect the rating of the project
• status: Open, Confirm, Resolve as fixed, Resolve as false positive, Resolve as won't fix; descriptions of the statuses are provided here

Users can also comment on the issue and assign labels/tags to it. The recommendations on how to use these elements are provided here.

In addition, SQ reports an estimated remediation effort, showing the time required to adequately address and fix the issue. 

By clicking on an issue, a reviewer can get a contextual description that includes the affected code snippet, with marked subject areas and recommendation provided by SQ rule that identified the issue. For example, code duplications may span across several locations in the code; SQ identifies and marks each of them, so that it is easier to spot them and evaluate their actual impact on the affected quality characteristic.

This is the basic mechanism for supporting the collaboration of reviewers with SQ. Reviewers are expected to cross-validate the findings reported by SQ by considering the context of the issue.

Measures screen

The Measures screen reports more in-depth data for each quality characteristic and code property (including also size and complexity). This screen provides low-level data and arguments for the issues reported in the Issues screen.

By default, SQ presents an overview (a diagram showing the relevance and priority of the issues, and the trend showing changes between consecutive scans made by SQ) and the aggregated lists of analyzed files affected by the specific type of issue. That helps in performing a more thorough analysis, restricted to a specific type of issue, and targeted at uncovering the root cause of it.

Code screen

The Code screen acts as a formatted preview of the recent code snapshot analyzed by SQ, grouped by the packages. The screen provides also line numbers, the commits that recently changed a given line (including the author, data and commit id). Next, it indicates lines covered by unit tests (in green) and not covered (in red).

The top-right corner provides also a condensed information about the file size, number of issues linked to currently open file and the test coverage metric (showing how completely the unit tests exercise the code in this file).

Activity screen

The Activity screen shows trend diagrams for selected metrics. Trends show how the subject metric(s) changed during subsequent SQ analyses. The data to be presented in the diagram can be customized by selecting the time period and the type of metric.