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 quality profile associated with the project. Developers can also manually raise issues that cannot be detected by SonarQube (examples: the implementation of the method does not comply to the functional requirements, the javadoc of the method does not match its implementation, etc.).
Each issue has one of five severities:
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.
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.
Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ...
Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ...
Neither a bug nor a quality flaw, just a finding.
Ideally, the team wouldn't introduce any new issues (any new technical debt). Plugins like Issues Report or SonarQube in Eclipse or SonarQube in IntelliJ can help developers because they provide 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.
- Confirm - By confirming an issue, you're basically saying "Yep, that's a problem."
- False Positive - Looking at the issue in context, you realize that for whatever reason, this issue isn't actually an issue, erm... "problem." It's not actually a problem. So you mark it False Positive and move on. It will disappear immediately from drilldwon drilldown and after the next analysis for issues counts.
- Change Severity - This is the middle ground between the first two options. Yes, it's a problem, but it's not as bad a problem as the rule's default severity makes it out to be. Or perhaps it's actually far worse. Either way, you adjust the severity of the issue to bring it in line with what you feel it deserves. The marker in the drilldown will change to show the new severity immediately, but the change won't be reflected in your issue counts until after the next analysis.