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:
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.
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.
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.
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!