Issues

Overview

While running an analysis, SonarQube raises an issue every time a piece of code breaks a coding rule. The set of coding rules is defined by the associated quality profile for each language in the project.

Ideally, the team wouldn't introduce any new issues (new technical debt). SonarLint helps developers by performing local analyses to check code before pushing it back to the SCM. But in real life, it's not always possible to catch all the issues while you code.

So new issues do get introduced.

Clean Code attributes

Clean Code attributes are characteristics your code needs to have to be considered Clean Code. When an issue is detected in your code, it means that this part of your code lacks one or more of these attributes, and it has an impact on the software qualities. For a detailed description of the attributes, see Clean Code.

Issue types

There are three types of issues:

1. Bug: A coding mistake that can lead to an error or unexpected behavior at runtime.
2. Vulnerability: A point in your code that's open to attack.
3. Code Smell: A maintainability issue that makes your code confusing and difficult to maintain.

Issue severity

The severity of an issue is determined based on its impact on the software qualities (see Clean Code) and cannot be edited. There are three levels: 

• High: Issues with a high or low probability to impact the behavior of the application in production, or represent a security flaw. For example, a memory leak, an unclosed JDBC connection, an empty catch block, or an SQL injection. Reviewing these issues should be a top priority. 
• Medium: A quality flaw that can highly impact the developer's productivity. For example, an uncovered piece of code, duplicated blocks, or unused parameters.
• Low: A quality flaw that can slightly impact the developer's productivity. For example, lines should not be too long, and "switch" statements should have at least 3 cases. This severity level also includes issues that are neither bugs nor quality flaws, just findings.

An issue can have multiple severities if it impacts more than one software quality. For example, an issue can have a high impact on the security of your software, but a low impact on its maintainability.

Severity mapping

The severity feature evolved in SonarQube 10.2. The following mapping was applied.

Understanding issue context

Sometimes, issues are self-evident once they're pointed out. For instance, if your team has agreed to an init-lower, camelCase variable naming convention, and an issue is raised on My_variable, you don't need a lot of background information to understand the problem. In other situations, context may be essential to understanding why an issue was raised. That's why SonarQube supports not only the primary issue location where the issue message is shown but also secondary issue locations. For instance, secondary issue locations are used to mark the pieces of code in a way that adds Cognitive Complexity to a method.

However, there are times when a simple laundry list of contributing locations isn't enough to understand an issue. For instance, when a null pointer can be dereferenced on some paths through the code, what you really need are issue flows. Each flow is a set of secondary locations ordered to show the exact path through the code on which a problem can happen. SonarQube supports multiple flows because there can be multiple paths through the code on which a resource is not released.

Check out this video for more information about understanding issues with multiple locations.

Issue lifecycle

Statuses

After creation, issues flow through a lifecycle, taking one of the following statuses:

The above statuses also apply to external issues.

SonarQube automatically reopens issues marked as fixed and not labeled as false positives when a subsequent analysis shows that they still exist.

Resolutions (deprecated)

• Closed: set automatically by SonarQube for automatically created issues.
• Removed: set automatically when the related rule is no longer available. The rule may not be available either because it has been removed from the quality profile or because the underlying plugin has been uninstalled.
• Resolve as Fixed: set automatically when a subsequent analysis shows that the issue has been corrected or the file is no longer available

About new issues

How new issues are identified

To determine the creation date of an issue, an algorithm is executed during each analysis to determine whether an issue is new or existed previously. This algorithm relies on content hashes (excluding whitespace) for the line the issue is reported on. For multi-line issues, the hash of the first line is used. For each file (after the detection of file renaming), the algorithm takes the base list of issues from the previous analysis and tries to match those issues with the raw issue list reported by the new analysis. The algorithm tries to first match using the strongest evidence and then falls back to weaker heuristics.

• If the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) : MATCH
• Detect block move inside the file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) : MATCH
• On the same rule, with the same message and with the same line hash (but not necessarily with the same line) : MATCH
• On the same rule, with the same message and with the same line number (but not necessarily with the same line hash) : MATCH
• On the same rule and with the same line hash (but not the same message and not the same line) : MATCH
• Is there a matching FIXED issue : MATCH and Reopen

Unmatched "base" issues are closed and considered fixed.

Unmatched "raw" issues are considered new.

Understanding issue backdating

Once an issue has been determined to be "new" as described above, the next question is what date to give it. For instance, what if the issue has existed in code for a long time but was only found in the most recent analysis because new rules were added to the profile? Should this issue be given the date of the last change on its line, or the date of the analysis where it was first raised? That is, should it be backdated? If the date of the last change to the line is available (this requires SCM integration) then under these circumstances, the issue will be backdated:

• On the first analysis of a project or branch.
• When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated).
• When SonarQube has just been upgraded (because rule implementations could be smarter now).
• When the rule is external.

As a consequence, it is possible that backdating will keep newly raised issues out of new code.

Automatic issue assignment

New issues are automatically assigned during analysis to the last committer on the issue line if the committer can be correlated to a SonarQube user. Note that currently, issues on any level above a file, for example, issues reported at a directory or project level, cannot be automatically assigned.

User correlation

Login and email correlations are made automatically. For example, if the user commits with their email address and that email address is part of their SonarQube profile, then new issues raised on lines where the user was the last committer will be automatically assigned to the user.

Additional correlations can be made manually in the user's profile. For more details, please see the documentation on Security under the Authorization header.

Known limitation

If the SCM login associated with an issue is longer than 255 characters including the characters for an issue author, the author will be left blank.

Issue edits

SonarQube's issues workflow can help you manage your issues. Other than fixing them in the code, you can perform the following actions on your issues: 

• Comment
• Assign
• Accept
• Mark as false positive

The Resolve as Fixed and Confirm actions are deprecated.

These actions break out into different categories.

Technical review

Actions that fall into this category presume an initial review of an issue to verify its validity. Assume that it's time to review the technical debt added in the last review period. This time period could be a day, a week, or an entire sprint. You go through each new issue and assign one of the following:

• False Positive: Looking at the issue in context, you realize that for whatever reason, this issue isn't actually a problem. So you mark it as a false positive and move on. This review assignment requires the Administer Issues permission level on the project.
• Accept: Looking at the issue in context, you realize that while it's a valid issue, it's not one that will be fixed now, so you mark it as accepted and move on. In other words, it represents accepted technical debt. This review assignment requires the Administer Issues permission level on the project.
• Resolve (deprecated): If you think you've fixed an open issue, you can Resolve it. If you're correct, the next analysis will move it to closed status. If you're wrong, it's status will go to re-opened.
• Confirm (deprecated): By confirming an issue, you acknowledge that the issue is a problem. Doing so moves it from Open to Confirmed.

If you tend to accept or mark a lot of issues as false positives, it means that some coding rules are not appropriate for your context. To solve this, you can:

• completely deactivate issues in the quality profile
• use issue exclusions to narrow the focus of the rules so they are not used on specific parts (or types of objects) of your application

As you edit issues, the related metrics, for example, new bugs being reported, will update automatically; as will the quality gate status if it's relevant.

Dispositioning

Once issues have been through technical review, it's time to decide who's going to deal with them. By default, issues are assigned to the last committer on the issue line (at the time the issue is raised), but you can certainly reassign them to yourself or to someone else. The assignee will receive an email notification of the assignment but only if they signed up for notifications, and the assignment will show up everywhere the issue is displayed, including in the My Issues list in the My Account space.

General

At any time during the lifecycle of an issue, you can log a comment on it. Comments are displayed in the issue detail in a running log. You have the ability to edit or delete the comments you made.

You can also edit an issue's tags. Issues inherit the tags of the rules that created them, but the tag set on an issue is fully editable. Tags can be created, added, and removed at will for users with the Browse permission level on the project.

Although they are initially inherited from the relevant rule, issue tags are not synchronized with the rule therefore, adding tags to a rule will not add those tags to the rule's issues.

Bulk change

All of these changes and more can be made to multiple issues at once using the Bulk Change option in the issues search results pane.

Purging fixed issues

By default, fixed issues are kept for 30 days. For more details, please see Housekeeping.

Opening issues in your IDE

From your Project's Issues page, pull up an issue’s detail view and select the Open in IDE button to open the issue in SonarLint. You’ll be prompted to set up Connected Mode if the project is not already bound. Understanding the issue in context will help you address it more effectively.

This feature is available to users of:

• SonarLint for IntelliJ 10.0 and above.
• SonarLint for Visual Studio 8.0 and above.
• SonarLint for VS Code 4.0 and above.
• SonarLint for Eclipse 9.1 and above.

It’s best if your project is already open in the appropriate IDE and bound to the server using Connected mode; if not, you will be prompted to set up a new connection. With SonarLint for IntelliJ, VS Code, and Eclipse, Automatic Connected Mode setup is available; with SonarLint for Visual Studio, the Open in IDE feature is only available for Security hotspots and you will need to have already set up Connected Mode beforehand. 

If you’ve already fixed the issue in your code, SonarLint will not be able to find it; only matching code will be highlighted. Keep in mind that the revision or branch analyzed by SonarQube may not be the same as what you have opened in the IDE. In this case, SonarLint will do its best to locate the issue in your local code. 

The Open in IDE feature will open security hotspots in all SonarLint IDEs. Please see the Security hotspots page for more details.