The latest expert opinions, articles, and guides for the Java professional.

The Wise Developers’ Guide to Static Code Analysis featuring FindBugs, Checkstyle, PMD, Coverity and SonarQube

Chapter I: Welcome to static code analysis, that thing you aren’t doing

“The quality of your code is a weak spot in almost every software project you’ll ever touch. This is because ongoing development ensures that even the bits you were once proud of become, over time, first less elegant, then rough, and finally incomprehensible.”

Oleg Shelajev, Java Developer/Author

Read it later! (pdf download)

Why should we monitor and fix code quality issues?

If we start at the very beginning, it would be with what we know about developers and their use of the tools and practices used to analyze code quality. There are a few things we found out about how developers think about code quality analysis, from Developer Productivity Report 2013 – How Engineering Tools & Practices Impact Software Quality & Delivery, which surveyed just over 1000 developers. Here’s what we saw:

wise developers guide to static code analysis do you monitor and fix code quality problems graph

  • 39% of developers don’t monitor code quality at all
  • 12% of developers monitor, but don’t fix issues
  • 41% of developers fix some code quality issues
  • 8% of developers fix all code quality issues

So, code quality analysis is not a terrible popular category to start with–which is probably one reason that most apps, even the best of them, suffer from creeping bugs and errors at some point. And do you know what else we found when we correlated these answers with others in the report?

Fixing code quality issues has a significant effect on, well, the overall quality of your code, as well as your ability to accurately predict when the software can be delivered to end users. Boom!

If the choice is between doing nothing and fixing all code quality issues that are identified, this is the analysis that emerged from the responses provided by the sample population:

wise developers guide to static code analysis effects of fixing code quality issues on predictability and quality graph

  • Developers reported up to 9% better predictability for app delivery
  • Developers reported up to 7% better app quality

The point here is, monitoring and fixing code quality issues is something that is proven to raise the quality of your application AND your ability to deliver that application to stakeholders on time. But it’s clear that the vast majority of developers aren’t taking full advantage of tools designed to improve app quality.

Perhaps most developers don’t know where to start. For developers, the main point can be summed up in one sentence:

How are you supposed to integrate your tool of choice into your development cycle so it can find relevant issues and allow the team to fix them?

There are many aspects of “code quality” that we can sink our teeth into, but we’ve decided that Static Code Analysis is an essential building block in your pyramid of tools that help improve the quality of your code. However, developers are using tools that fit into other categories as well, such as:

Dynamic Code analysis
The simplest difference between Static and Dynamic analysis tools is that the former runs in the development environment and the latter needs to be active during the runtime of the application under analysis. Typical dynamic code analyzers profile your system and monitor its health. Both execution time and memory usage profilers, figuring out number of database transactions per request, the average size of an user session object, etc. require the system to be under a load comparable with the intended in production environment. Dynamic analysis tools often instrument the code to add tracing of method calls, catching and notifying about exceptions, and any other statistics they collect.

Performance is a magical term that never fails to generate interest. Figuring out why your system is slow and how to make it faster is a rewarding exercise. Combine this with the fact that you can continue optimizing forever (as something will always be a bottleneck), performance-related tasks are always picked first by developers. It just sounds so cool, and it’s also measurable too.

Memory tools
Most of existing tools that deal with memory management either provide some high level statistics in real-time, like telling you the size of the heap and the number of classes loaded into the JVM, or work in an offline mode feeding on some traces produced during a run. Garbage collector’s logs, object allocation rates, ability or inability to refresh the memory taken by the classloader of your web-application, these are questions usually attacked with a tool analyzing your application’s memory behavioral patterns.

Monitoring tools
Monitoring tools are known to everybody, often these are the last man standing before a service goes offline because of some resource limits.

Naturally, there are a lot of questions to ask before you start to use any of the tools we discuss later, so in this report we show you what aspects are important to consider when getting started.

Download the PDF

Responses (4)

  1. Avatar  

    Craig D

    April 22, 2014 @ 4:24 pm

    Regarding Heartbleed, Coverity had OpenSSL on its list of scanned open-source projects (, but its tool did not find the Heartbleed bug. To their credit, since Heartbleed the Coverity tool is being modified to detect the bug. For details see:

  2. Avatar  

    Oliver White

    April 23, 2014 @ 12:12 pm

    Interesting, thanks for sharing!

  3. Avatar  


    May 5, 2014 @ 4:47 pm

    Thanks for the article.
    SonarQube positions itself as a replacement for PMD+FindBugs+Checkstyle+etc:
    Have you investigated what’s their current “coverage” and if their plans are viable?
    If they succeed that would be a big step forward in code conventions enforcement.

    Some of the common issues building “cross-dev-tool” (Java) project that I’ve observed:
    * Checkstyle is different than codestyle, supported by IDE
    * IDEs have different codestyle conventions formats and handle formatting differently
    * IDEs provide their own partial implementations of code checks (duplication of effort)
    * Plugin hassle
    ** Need to install 3-4 additional plug-ins for IDE
    ** Configuring rules at Maven level is not the same as configuring rules at IDE level
    ** Each IDE has its own specifics of defining rules
    * It’s very hard to apply different code conventions for different pieces of code (e.g. operating code is different from unit-test code)
    * It’s hard to re-use configurations (by “hard” I mean something that goes beyond including Maven dependency)
    * Developers prefer writing their own rules implementations skipping available APIs

    Almost forgot: there are also architecture-level checks and rules, which might be implemented as
    * Structure101
    * Custom code

    Sounds like a JSR?

  4. Avatar  

    Marat Boshernitsan

    November 19, 2014 @ 8:46 pm

    Great article, thanks!

    Coverity recently announced a hosted static-analysis-as-a-service product called Code Spotter (, currently in free and unlimitted beta. It’s using the same analysis engine as the Coverity enterprise product, but it is wrapped in a different (simplified) user interface. You might want to check it out to get a sense of the Coverity analysis capabilities.

    Code Spotter is Java-only, for now, but other Coverity supported languages should be coming soon.

RSS feed for comments on this post.

Leave a comment