Chapter 2. Issues and coding standards
This chapter covers
- Looking at your issues
- What issues mean
- Where issues come from
If you’re only using your users’ bug reports to measure the bugginess of your code, then you’re only seeing a tiny sliver of the picture—because users can only report what they can perceive. Any user will recognize a program crash, but what about gradual performance degradation caused by unclosed database connections?
The report that comes back from the users typically sounds like “sometimes it gets slow and we have to restart.” Which could, of course, mean anything.
In this chapter, we’ll look at issues: programming errors that users aren’t necessarily noticing...yet. Pay attention to coding rule issues, and you can head that bug report and many others off at the pass by preventing problem code from ever reaching the user.
The term issues covers two of SonarQube’s Seven Axes of Quality: potential bugs, and coding standards. We’ll start with what SonarQube tells you about issues on the dashboard and in the issues drilldown. Then we’ll look at why each issue is a potential problem, even the ones you might be tempted to shrug off.
Next we’ll take a brief look at rule profiles—the sets of rules against which your code is measured in an analysis—and how to change the defaults. We’ll round out the chapter with a summary of issues-related plugins that might be of interest.