Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

We know you aren’t fixing code quality issues (but you should)


Do you use tools that help you identify and fix issues in your code? These are often called “code quality tools”, and as we can see in the graph above (taken from Developer Productivity Report 2013 which surveyed just over 1000 developers), a slight majority of respondents (51%) do not take action of any kind regarding code quality problems. And if only 8% fix all code quality problems they see, does this mean that 92% of apps out there are running with bugs that could have been fixed before they even went live?

That’s scary. Luckily, the Java ecosystem provides many tools that do code analysis and find bugs or style deviations in your code base. Code quality tools are meant to analyze the source code of an application or compiled artifacts to bring to light any flaws or inefficiencies.

Originally, the area of code quality analysis focused on the security flaws, because these are the most crucial issues that can haunt you. But this approach evolved into also reviewing code style, formatting compliance and identifying bad practices that have crept into the codebase (not blaming you…).

There are a lot of questions to ask before you start to use code quality tools, and in our upcoming report from RebelLabs, we’ll show you what aspects are important to consider when getting started–e.g. how to install and integrate your tool of choice, how to avoid getting 10,000 errors 5 minutes after starting up (customizations), common pitfalls to watch out for, and more. The main point for you as developers is:

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?

In this post, we only want to introduce different approaches that code quality tools pick in order to analyze your code and look at a way to categorize the tools. Within each category, we’ll look at some of the tools most of us use to get a better idea about what those represent.

Types of code analysis tools

Based on the statistics that we gathered in 2012, it is clear that only a minority of Java projects enjoy the benefits of static code analysis tooling. The leader of the tools employed for that was FindBugs, which was used by the third of the respondents. However, the lack of a true leader in this area–such as Eclipse, Tomcat or Jenkins–just goes to show that these tools do NOT all work the same way, contrary to what some might think.


However, we feel that the adoption of the code analysis tools should be wider. The cost of enhancing your build process with any of the tools mentioned in the image above is somewhat minor; however, interpreting the results and taking action based on them might be trickier and, actually is a topic for another discussion, just having the infrastructure up and ready can help with preventing some issues.

The principal difference between the tools lies in their input type. If you are what you eat, then your software is mostly what it takes as an input. Which is totally not true, but that’s another story. In any case, the development process of an application offers just a few artifacts that our code quality analysis tools can consume:

  • source code
  • compiled artifact: bytecode or executable
  • test run information
  • long-running instance monitoring statistics

Naturally, there are tools that work on every item from this list. Source code and bytecode are available for no additional price from within your IDE, so many tools that require just these are moving there in form of plugins or optional components.

Improving code quality with Static Code Analyzers

Static code analyzers work on your code and are most often available as features in your IDE. Noticing things like missing brackets around flow control blocks and incorrect handling of exceptional situations, unreachable code & unsanitized user input, these tools make your code prettier and more robust.

The cleaner the codebase, the happier the developers. It is always calming to know that someone will look through the code you push into the master, even if it is just a heartless code analyzer. Finding bugs early doesn’t let you get out of the flow and loose the understanding of what is happening in the code you just modified.

This leads to less errors slipping into the final artifacts, and despite the fact that most of the things that get caught by these tools are trivial and mostly harmless, preventing a couple of real errors makes it worth it. As we all know, even a minor bug appearing in a critical place can ruin your day and make your clients trust you less.

Source code analyzers


The main advantage of working on the source code level is, surprise, seeing the code as you type it, instead of going through a compiled version and guessing how you originally specified that obscure chain of byte instructions.

One obvious advantage of working with the source directly is the ability to verify code’s compliance with a predefined style. In theory, source code analyzers should be more powerful than their counterparts that consume the compiled inputs, because some information gets lost in the compilation. When we speak of Java for example, the most known thing that gets erased from the bytecode is generics of course.

Another benefit from working with the source directly is that it provides the easiest integration with IDEs and makes detailed feedback pointing to the exact line or statement in the code easier.

Checkstyle and PMD are great examples of source code analyzers that do more than just checking the source code layout and gnaw you about the line endings.

Bytecode analyzers


Bytecode analyzers operate on the compiled artifact, which makes reasoning about the code style questions much harder. However, the structure of the bytecode language is much simpler than the source code. Which makes a deeper analysis possible.

The most used tool in this category is no doubt FindBugs, but there is also JLint as well.

High-level Project Analyzers (aka “birds-eye” viewers)


You might know that the complexity of a project is not uniformly distributed through the whole codebase. Dependencies between the modules, vertical layers of the application logic, horizontal aspects that invisibly slice the whole system and add complexity to every part of it are making your life as a developer harder.

Questions to ask here are:

  • What components depend on each other?
  • Are there any circular dependencies?
  • What happens if you change the implementation of module XYZ?
  • Do you imagine the data flow graphs of the system?

A level of analytics that goes beyond just the missing braces is required to answer to these questions. Luckily, there are tools that can help you with understanding the project better on this level as well.

Check out Atlas or SonarGraph-Quality to get an impression of what these tools are and how can you benefit from enabling them on your project.

Wait, what about Sonar?


SonarQube (aka Sonar) is a platform used to manage all sorts of different aspects of code quality and technical debt reduction, and many development teams out there simply add other tools like Findbugs and Checkstyle onto SonarQube and use it that way. It gives you a high-level overview and lets you integrate all kinds of other code quality tools we were talking about, plus it combines the output of these tools with a historical view on your project, so you get to see trends and act based on the full picture instead of being placed at the mercy of a single build result.

Conclusion: You should be using code quality tools

As we’ve seen, static analysis tools come in different flavours, despite doing approximately the same job of scanning through the codebase to detect flaws and inefficiencies.

They all have the same goals but different ways of achieving them.

Source code analyzers can be very powerful and are probably the closest ones to the developers, being integrated into all IDEs and showing their output right into dev’s faces. Bytecode analysis is somewhat simpler to implement, and given the popularity and ease of use of FindBugs, we think is a great way to enhance your build process. Other tools focus on the big picture of your project, showing architectural quirks and pointing to where you violated design patterns with those nasty circular dependencies no one will understand a year later.

Stay tuned for the full report coming up in a few weeks time, and feel free to tell us your horror stories about code quality in the comments below, or ping me on Twitter: @shelajev!

Visit our All Reports page dude!

  • Don

    It’s not scary that programs ship with bugs. It’s inevitable. On any program with more than one developer, source code is a tragedy of the commons.

    Among programmers, if “8% fix all code quality problems they see” (I find it hard to believe it’s anywhere near that high), that means 92% of programmers are free to add features and improve performance, confident that this small fraction of their colleagues will be bogged down with fixing every last bug.

    Personally, I’d love to have a job that let me fix every single bug in a program, without responsibility for any new work, but every professional team I’ve worked on had a PM, and no PM I’ve ever met would ever sign off on letting a programmer spend all of their time fixing bugs. Customers sometimes say they want zero bugs, but not after they hear how much time and money it’s going to cost.

    If fixing all errors found by automated tools was so important, why does this blog post have 23 validation errors in its HTML alone? Surely you don’t believe what you wrote.

  • Oleg Šelajev

    It’s not _that_ scary that code ships with bugs. However, even if a small number of them could be prevented by a certain established process, which is mostly automated, isn’t it great?

    Also, you wouldn’t expect that a code analyzer will fix them for you, would you? So the responsibility of looking at the reports, tweaking rulesets to limit the number of false positives, and managing the codebase is still on the development team. Personally, I think, it’s great that there are tools that can help you focusing your attention on smaller parts of the code, and I’ll take that help anyday.

    A bad PM is another problem, which unfortunately, cannot be solved with software, but then PMs should not dictate how to treat the source code. Yeah, I like to believe in miracles.

    Finally, about the html errors, you’re very observant, thank you. We’ll probably check them. The good thing is that ZeroTurnaround isn’t known for maintaining blogging platforms. Check out our products, JRebel, LiveRebel, I promise we do run code analyzers on them and treat their output with respect :)