Infer is a static code analysis tool promising finding many bugs that escape the attention of many other tools. My curiosity was piqued. The result was underwhelming: Infer found four possible NullPointerExceptions in the source code of BootsFaces. Later I ran SonarQube. It found many other potential NullPointerExceptions. Any in both cases, half of the findings where false positives.
Since version 2.0, TypeScript has a built-in NPE finder. It works very well. Of course, it sometimes finds false positives, too. But if you activate the compiler switch --strictNullChecks from day one, that's not a big problem because you notice the problem while you're writing the code. You can tell the compiler to ignore the non-bug in a couple of seconds.
Should you use static code analysis at all?
Some people argue that things like strong types and static code analysis are a waste of time. For example, Xiao Chen mentions at Quora that PMD finds a bug in every third line of the JDK's package java.util. According to this standard, Java is too buggy to use in production. Luckily millions of developers, administrators, companies, and happy Android users aren't aware of that. As it turns out, Java does work. PMD just reports a lot of weird stuff.
Eric Eliott even reports that strong types make you feel more productive,, but that there's "scientific" proof that the contrary is true.
Just in case you're confused why I mention static code analysis and strong types in the same article: in my eyes, they are closely related. The compiler is a static code analysis tool even if it's hardly ever called one.
Cutting a long story short, I'm convinced both strong types and static code analysis is worth the pain. They are usually a pain in the ass when you start the project, but after a while, the advantages become visible.
Configuring SonarQube
There are many static code analysis tools: PMD, Findbugs, checkstyle, and many more. Let me introduce you to a tool with a nice UI. When I heard about it first, I thought it was just a nice UI for PMD, checkstyle, and Findbugs. This doesn't seem to be true, but from the developer's point of view, it's close enough.
The problem with tools like Sonarqube is the incredible number of rules they enforce. In earlier times, Sonarqube used to offer some 700 rules for the Java language (plus the rules for C#, JavaScript, PHP, Python, XML, and Flex). The version I tested today is a lot more manageable. By default, 285 rules are active, plus 145 inactive rules.
Even so, prepare for several hours (or even days) of configuring. The vast majority of rules are debatable. Many rules are a matter of taste, such as naming conventions. If you're using your own naming conventions, you have to teach them to Sonarqube (or PMD, or Checkstyle, or whatever) first. I suppose that's why PMD finds so many violations in java.util.
Using SonarQube
You can integrate SonarQube with your Maven or Gradle scripts. There's even an integration with most Java IDEs. That's a great feature because nobody wants to start a tool just to see how bad their code is.
Actually, that's precisely the reason why Sonarqube didn't work in most projects of mine. There's no immediate feedback. Integrating the tool with the continuous integration tool helps. If your last commit adds new rule violations to the code, you'll receive an email. Even so, it's almost impossible to add a tool like SonarQube to an existing project. The developers see there are one thousand rule violations. That's too much to fix in reasonable time, so they won't even start.
The SonarQube team seems to be aware of the problem. When I ran it with Bootstrap, the "quality gateway" semaphore was green. It only got red after my first commit after installing SonarQube. The semaphore didn't analyze the entire code, but only the new code. Sound's like a good compromise to me.
Detectings NPEs with SonarQube
If I'm not mistaken, SonarQube analyzes the code file by file. It can detect NullPointerExceptions if everything happens in the same file. For instance, if the NPE is caused by calling a method returning null, the bug can only be detected if the method is defined in the same file. Obviously, there's room for improvement. However, when SonarQube detects an NPE, it explains it very nicely:
Detecting NPEs with Infer
Infer is a command-line tool which is much more ambitious. It doesn't analyze individual files. It analyzes the entire project. In theory, this allows it to detect NPE missed by most other tools.
When I tried it, it detected four bugs in BootsFaces. Among those four bugs, two were false positives, but Infer couldn't know this. I wonder why SonarQube detected more bugs than Infer. Infer is at least two years old, and more than 3500 commits went into it. That doesn't sound like immature software. Nonetheless, I suggest using Infer as an additional tool because of its limited scope. The good news is that it's easy to integrate Infer in your build process or your Continuous Integration tool.
Detectings NPEs with TypeScript or Ceylon
Both TypeScript and Ceylon allow you to detect NullPointerExceptions a lot earlier. They've baked null safety into the programming language, so the compiler detects NPE both within a file and across files. I've blogged about Kotlin's built-in NPE detection some time ago. Hight recommended.
Developers coming from a JavaScript background usually shy away from this feature, and for a good reason. JavaScript libraries are often written in a way making it difficult to adopt null safety. The same applies to many Java libraries. That's why both TypeScript and Kotlin allow you to opt-in for null values.
Detecting resource leaks
There's much more to static code analysis than just null pointers. The tools have accumulated a lot of debatable rules. Rules being useful in one project, but not in the next project. but there are a few gems among these rules.
One of these rules detects resource leaks. If you're not using the try-with-resources of Java 7, you probably open a file and forget to close it if an error occurs. SonarQube (and similar tools) can detect this and several similar bugs.
Detecting security problems
I've also seen a project on the OWASP site dedicated to detecting security problem using static code analysis. This project seems to be in the early incubator phase, but even so, it shows the potential of static code analysis.
Wrapping it up
Many developers (and probably even more project managers) appreciate static code analysis. As to my experience, it's a bit overrated. But it's a useful tool nonetheless. The challenge is to separate the wheat from the chaff. Every static code analysis tool offers hundreds, if not thousands of rules. It's a good idea to limit the analysis to a few, really useful rules.
Another challenge is to organize your workflow including the static code analysis. More often than not, there's a forgotten SonarQube server that's crashed months ago without anybody noticing. So try to make it a game.