* [bad-practice](https://rules.sonarsource.com/java/tag/bad-practice) - the code likely works as designed, but the way it was designed is widely recognized as being a bad idea.
* [cert](https://rules.sonarsource.com/java/tag/cert) - relates to a rule in a [CERT](https://www.securecoding.cert.org/confluence/x/BgE) standard. There are currently three CERT standards: [C](https://www.securecoding.cert.org/confluence/x/HQE), [C++](https://www.securecoding.cert.org/confluence/x/fQI), and [Java](https://www.securecoding.cert.org/confluence/x/Ux). Many of these rules are not language-specific, but are good programming practices. That's why you'll see this tag on non-C/C++, Java rules.
* [clumsy](https://rules.sonarsource.com/java/tag/clumsy) - extra steps are used to accomplish something that could be done more clearly and concisely. (E.G. calling .toString() on a String).
-* [confusing](https://rules.sonarsource.com/java/tag/confusing) - will take maintainers longer to understand than is really justified by what the code actually does
+* [confusing](https://rules.sonarsource.com/java/tag/confusing) - will take maintainers longer to understand than is really justified by what the code actually does.
* [convention](https://rules.sonarsource.com/java/tag/convention) - coding convention - typically formatting, naming, whitespace...
* [cwe](https://rules.sonarsource.com/java/tag/cwe) - relates to a rule in the [Common Weakness Enumeration](http://cwe.mitre.org/). For more on CWE and on security-related rules in general, see [Security-related rules](/user-guide/security-rules/).
* [design](https://rules.sonarsource.com/java/tag/design) - there is something questionable about the design of the code
* [lock-in](https://rules.sonarsource.com/java/tag/lock-in) - environment-specific features are used
* [misra](https://rules.sonarsource.com/java/tag/misra) - relates to a rule in one of the [MISRA](http://www.misra.org.uk/) standards. While the MISRA rules are primarily about C and C++, many of them are not language-specific (E.G. don't use a float as a loop counter) but are simply good programming practices. That's why you'll see these tags on non-C/C++ rules.
* [owasp](https://rules.sonarsource.com/java/tag/owasp) - relates to a rule in the [OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) security standards. Note, that the OWASP Top Ten is a list of high-level vulnerabilities which translates to many, many potential rules.
-* [pitfall](https://rules.sonarsource.com/java/tag/pitfall) - nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next guy and he'll probably fall into it and screw up the code.
+* [pitfall](https://rules.sonarsource.com/java/tag/pitfall) - nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next person, and they'll probably fall into it and screw up the code.
* [sans-top25](https://rules.sonarsource.com/java/tag/sans-top25) - This tag is based on outdated statistics and should no longer be used. Instead, it's recommended to rely on the "CWE Top 25" reports, which are available in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).
* [suspicious](https://rules.sonarsource.com/java/tag/suspicious) - it's not guaranteed that this is a **bug**, but it looks suspiciously like one. At the very least, the code should be re-examined & likely refactored for clarity.
* [unpredictable](https://rules.sonarsource.com/java/tag/unpredictable) - the code may work fine under current conditions, but may fail erratically if conditions change.
url: /user-guide/issues/
---
-While running an analysis, {instance} raises an issue every time a piece of code breaks a coding rule. The set of coding rules is defined through the associated [Quality Profile](/instance-administration/quality-profiles/) for each language in the project.
+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 through the associated [Quality Profile](/instance-administration/quality-profiles/) for each language in the project.
### Issue Types
Each issue has one of five severities:
1. **BLOCKER**
-Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed.
+Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be fixed immediately.
1. **CRITICAL**
Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed.
1. **MAJOR**
1. **INFO**
Neither a bug nor a quality flaw, just a finding.
-Ideally, the team wouldn't introduce any new issues (any new technical debt). [SonarLint](https://sonarlint.org) 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 code without any new technical debt, and sometimes it's not worth it.
+Ideally, the team wouldn't introduce any new issues (any new technical debt). [SonarLint](https://sonarlint.org) can help developers by letting you perform local analyses to check your code before pushing it back to the SCM. But in real life, it's not always possible to code without any new technical debt, and sometimes it's not worth it.
So new issues get introduced.
## 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 {instance} 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.
+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 SonarQube 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, {instance} supports multiple flows.
+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. And because there can be multiple paths through the code on which, for instance a resource is not released, SonarQube supports multiple flows.
Check out this [ video](https://youtu.be/17G-aZcuMKw) for more on issues with multiple locations.
-## Issues lifecycle
+## Issues lifecycle
+
### Statuses
-After creation, issues flow through a lifecycle, taking one of five possible statuses:
+After creation, issues flow through a lifecycle, taking one of the following statuses:
-* **Open** - set by {instance} on new issues
+* **Open** - set by SonarQube on new issues
* **Confirmed** - set manually to indicate that the issue is valid
* **Resolved** - set manually to indicate that the next analysis should Close the issue
-* **Reopened** - set automatically by {instance} when a Resolved issue hasn't actually been corrected
-* **Closed** - set automatically by {instance} for automatically created issues.
+* **Reopened** - set automatically by SonarQube when a Resolved issue hasn't actually been corrected
+* **Closed** - set automatically by SonarQube for automatically created issues.
### Resolutions
-Closed issues will have one of two resolutions:
+Closed issues will have one of the following resolutions:
* **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)
* **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.
-Resolved issues will have one of two resolutions:
+Resolved issues will have one the following resolutions:
* **False Positive** - set manually
* **Won't Fix** - set manually
### 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 deactived or is no longer available (ie: plugin has been removed) => Resolution: Removed
+* an issue (of any status) has been properly fixed = Resolution: Fixed
+* an issue no longer exists because the related coding rule has been deactived 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 Resolution is not False positive) is shown by a subsequent analysis to still exist
+* an issue that was manually Resolved as Fixed(but Resolution is not False positive) is shown by a subsequent analysis to still exist.
## Understanding which Issues are "New"
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 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.
Unmatched "raw" issues are new.
## Understanding Issue Backdating
-Once an issue has been determied 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 (this requires [SCM integration](/analysis/scm-integration/)) then under certain circumstances, the issue will be backdated:
+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 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](/analysis/scm-integration/)) then under certain circumstances, the issue will be backdated:
* On 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)
## Automatic Issue Assignment
### For Bug, Vulnerability and Code Smell
-New issues are automatically assigned during analysis to the last committer on the issue line if the committer can be correlated to a {instance} user. Note that currently, issues on any level above a file, e.g. directory / project, cannot be automatically assigned.
+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, e.g. directory / project, cannot be automatically assigned.
### User Correlation
-Login and email correlations are made automatically. I.e. if the user commits with her email address and that email address is part of her {instance} profile, then new issues raised on lines where she was the last committer will be automatically assigned to her.
+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 (see "SCM accounts" in Authorization for more).
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
-{instance}'s issues workflow can help you manage your issues. There are seven different things you can do to an issue (other than fixing it in the code!): Comment, Assign, Confirm, Change Severity, Resolve, Won't Fix, and False Positive.
+SonarQube's issues workflow can help you manage your issues. There are seven different things you can do to an issue (other than fixing it in the code!): Comment, Assign, Confirm, Change Severity, Resolve, Won't Fix, and False Positive.
These actions break out into three different categories. First up is the "technical review" category.
As you edit issues, the related metrics (e.g. New Bugs), 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 them. By default they're 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 someone else. The assignee will receive email notification of the assignment if he 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.
+Once issues have been through technical review, it's time to decide who's going to deal them. By default they're 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 someone else. The assignee will receive email notification of the assignment 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.
projects / sonarqube.git / commitdiff