Chapter 11. IDE integration
This chapter covers
- What’s supported
- Setting up Eclipse
- Working your assigned issues
- Running a local analysis
Rules that show you what’s wrong and rule descriptions that point you in the right direction for fixing the problems can help green developers become good developers, and good developers become even better. SonarQube gives you both.
But with SonarQube in place, your code quality is visible. Mistakes are no longer private or anonymous—the SCM Activity plugin pastes your ID next to each line of code like a billboard. Now there’s team and even management focus on mistakes.
Of course, visibility into code quality is supposed to be a good thing. Co-ownership of the code and team spirit (agile practices) should focus on getting things done, not on placing blame. After all, issues aren’t for pointing the finger but for increasing software quality. In the best situations, that’s exactly what happens: each issue is a teaching opportunity. But in other situations, the attention SonarQube brings to code quality isn’t always positive.
It’s been likened to cruising down a highway and suddenly finding yourself in a lazy little speed trap of a town. Sure, SonarQube posts the speed limit; but if you don’t know how fast you’re going until after the cop tells you what speed he clocked you at—after the next analysis runs—well, it can seem a little unfair.