Issues

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

Ideally, the team wouldn't introduce any new issues (any new technical debt). SonarLint can help developers because it provides the ability to perform local analyses to check their 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 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 the issue has an impact on the software qualities. For a detailed description of the attributes, see Clean Code.

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 severity 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. These issues must be immediately fixed.
• 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 has evolved. It is no longer possible to change the severity of an issue. Severity is now determined based on the impact on the software qualities. For reference, note that 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 a init-lower, camelCase variable naming convention, and an issue is raised on My_variable, you don't need a lot of context to understand the problem. But in other situations, context may be essential to understanding why an issue was raised. That's why SonarCloud supports not just the primary issue location, where the issue message is shown, but also secondary issue locations. For instance, secondary issues locations are used to mark the pieces of code in a method which add cognitive complexity to a method.

But 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. And because there can be multiple paths through the code on which, for instance a resource is not released, SonarCloud supports multiple flows.

Opening issues in your IDE

To speed up the time it takes to find and fix the issue, you can open the issue in your IDE provided the Connected Mode has been properly set up in order to connect SonarLint with SonarCloud. 

To open an issue in your IDE:

1. Retrieve the issue and open its detail view as described above in Retrieving issues. 
2. From any of the Issues tabs, select Open in IDE. 

Issues lifecycle

Statuses

After creation, issues flow through a lifecycle, taking one of five possible statuses:

• Open: set by SonarCloud on new issues.
• [deprecated] Confirmed: set manually to indicate that the issue is valid. 
• False Positive: the analysis is mistaken.
• Accepted: set manually to indicate that the issue is valid and that it won’t get fixed now. Requires Administer Issues permission level on the project.
• [deprecated] Fixed: set automatically when a subsequent analysis shows that the issue has been corrected or the file is no longer available (removed from the project, excluded, or renamed).

These statuses also apply to external issues. 

Issue workflow

Issues are automatically closed (status: Closed) when:

• an issue (of any status) has been properly fixed => Resolution: Fixed
• an issue no longer exists because the related coding rule has been deactivated or is no longer available (ie: plugin has been removed) => Resolution: Removed

Issues are automatically reopened (status: Reopened) when:

• an issue that was manually Resolved as Fixed (but the Resolution was not marked as a False positive) is shown by a subsequent analysis to still exist

Method used to identify if an issue is new

SonarQube and SonarCloud use the same algorithm to determine whether an issue is new or existed previously:

• For each issue found in the file from the previous analysis, it compares it to each issue found in this file during the current analysis:
  • If there is no match then it considers the issue as Fixed.
  • If there is a match and the issue status is Fixed in the previous analysis then it reopens the issue.
• For each issue found in the file during the current analysis, if there is no matching issue in the file from the previous analysis then it is considered new.

This algorithm relies on the issue's line hash. The line hash is calculated based on the content of the first line the issue is reported on, excluding the white spaces.

The figure below shows the comparison process between two issues.

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 it has existed in code for a long time, but 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 then under certain 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 the analyzer 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 the New Code Period.

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 SonarCloud user. Note that currently, issues on any level above a file, for example in a directory or project, cannot be automatically assigned.

User correlation

Login and email correlations are made automatically, i.e. if the user commits with their email address and that email address is part of their SonarCloud profile, then new issues raised on lines where they were the last committer will be automatically assigned to them.

Additional correlations can be made manually in the user's profile (see "SCM accounts" in Authorization for more).

Known limitation

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

Issue edits

SonarCloud's issues workflow can help you manage your issues. There are five different things you can do to an issue (other than fixing it in the code!): leave it Open, Accept the issue, mark the issues as False Positive, Tag the issue, or leave a Comment.

These Status changes can be assessed during a technical review, during Disposition, or commented upon at any point during the issue lifecycle.

Technical review

The Accept and False Positive actions (along with the deprecated Confirm and Fixed actions) fall into this category, which presumes 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 - whether that's a day, a week, or an entire sprint: Go through each new issue and select one of the following:

• Accept: Looking at the issue in context, you realize that while it's a valid issue it's not one that actually needs fixing. In other words, it represents accepted technical debt. So you mark it as accepted and move on. Requires the Administer issues permission on the project.
• 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 False Positive and move on. Requires the Administer Issues permission on the project.
• [deprecated] Confirm: If you were using Confirm to communicate with team members, consider assigning the issue or using comments and tags instead. You can also consider marking it as Accepted.
• [deprecated] Fixed: If you were using Fixed to communicate with team members that an issue is being fixed, consider assigning it or using comments and tags instead.

If you tend to mark a lot of issues False Positive or Accepted, it means that some coding rules are not appropriate for your context. So, you can either completely deactivate them in the quality profile or 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. Similarly, making a lot of severity changes should prompt you to consider updating the rule severities in your profiles.

When you edit issues, the related metrics and, if relevant, the quality gate status will update automatically.

Dispositioning

Once issues have been through technical review on the main Issues page by a project administrator, 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 reassign them to yourself or to someone else. The assignee will receive email notification of the assignment but only if he/she signed up for notifications; the assignment will show up everywhere the issue is displayed, including in the My Issues tab as shown in this image:

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. Users with the Browse permission on the project can create, add, and remove tags at will.

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

Bulk change

Using the Bulk Change option in the issues search results pane, you can make all of these changes and more to multiple issues at once.

Purging closed issues

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

[Deprecated] Issue types

Issue types are deprecated. Issues are now tied to Clean Code attributes and software qualities impacted (see Clean Code).

There are three types of issues:

1. Bug: A coding error that will break your code and needs to be fixed immediately.
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.