Use Static Code Analysis Tools

In the Olympic discipline of the high jump, the athlete has to jump over a bar, and during a competition, the bar is raised higher and higher until only a single athlete can jump over it. The world record is 2.45 m. Static analysis tools provide such a bar for the quality of your code. They investigate your code and look for potential bugs or code smells. That’s more than just compiling and running the tests; hence it’s a higher bar you have to jump over. It’s also one step closer to a realistic development and production environment. These tools are usually efficient and quick to use. Even if they’re not perfect and might report false positives, they can help you catch mistakes that don’t break your code but that reduce its quality.

Most of the comparisons in this book describe accidental mistakes and code smells that are in some sense similar to what static analysis tools are looking for. If you’re a beginner, it can take some time for them to sink in, and you’ll need practice to spot them in real projects. That’s also the case when there’s not enough time to take a step back and think about code quality—for example, when moving fast in large code bases. Of course, experienced developers will find such problems during code review, but their time is costly. Also, if you’re drowning in a sea of smaller problems that a static analysis tool could have found, chances are you’ll overlook the big issues that it doesn’t find.

Static code analysis tools can automatically detect certain types of problems in your code beyond compile and functional errors, and some even help you to fix them. Large code bases are no problem to analyze. And the best part: many of them are open source and free to use. No one’s saying you should apply every tool out there, but there’s also a good reason to use at least one of them—it can also improve the quality of your code. The point of this section is to give you an overview of the most important tools for Java.

SpotBugs,^[47] or its predecessor FindBugs, is one of the oldest static code analysis tools for Java. It detects over 400 types of potential bugs.^[48] Yep, that’s a lot. SpotBugs provides textual help only—it points you to a problematic piece of code in a report file or your IDE, but it doesn’t suggest a copy and paste–ready fix. Some of the bugs it spots might be false positives, so every time you get a warning, you should check whether it’s a real problem. SpotBugs is helpful because a large community of developers worked to build good bug detection strategies.

Checkstyle^[49] and PMD^[50] are two other popular tools that are quite similar to SpotBugs. Their main difference is that they’re highly configurable, which makes them a powerful help if you want to ensure a certain code style. The downside is they’re quite verbose, and you’ll usually want to configure them specifically for your project, which can be tricky. In their default configuration with a full rule set, they’ll report issues in numbers that are an order of magnitude higher than for SpotBugs—some of which might even be opinionated or contradict each other. That’s why we usually build a custom configuration with the rules that are important for our project, especially the ones that enforce the Java code conventions and check for the problems that are covered in this book.

Error Prone^[51] is yet another popular static analysis tool that’s more of an enhancement to the Java compiler. It performs more advanced type checks and, thankfully, provides suggestions for fixes to the numerous issues it can find. It’s built by Google for their own Java code base, but the tool is open source. Error Prone became famous when it detected a bug^[52] in ConcurrentHashMap, an API class that was in production for some time and widely believed to be bug-free. We like to use Error Prone in our projects because it produces a very low number of false positives, and if it finds something, it also provides a suggestion for a fix.

Lastly, some Java IDEs come with built-in support for static analysis. For example, the IntelliJ IDEA has a feature named Code Inspection^[53] that can automatically detect issues in your code, very much like the tools we discussed above. The best part is that it also proposes fixes, and you can refactor the code with a click. Even if you’re not using IntelliJ, you should check what your IDE can do for you out-of-the-box.

To sum up, static analysis tools are very useful and efficient for finding problems in your code that the compiler or tests won’t find. There are plenty of tools available in the Java ecosystem, and you should apply at least one of them to help you maintain a high quality. They also help to enforce a common Java code format in your team.