Kinds of Static analysis tools
I like clean code. I like code where is visible quality with the first touch of code. And I like predictable codebases which look as written by one developer. And I like static analysis because it significantly helps to achieve all the mentioned things. In my last article I wrote about mistakes in using static analysis in software projects. Now I would like to go a step forward and give advice how to choose the right tool(s). I would say that even with a subset of these tools you will have enormous benefits as fewer bugs, better maintainability, cleaner and simpler code. Let’s start with a theory and motivation.
One tool is almost nothing
When it comes to choice static analysis tools, in the first line of possibilities are tools widely accepted by the community - in Java landscape PMD, FindBugs and CheckStyle. One of these tools is almost on each project, but rarely there are more than two of them. And it’s wrong! Maybe is hard to convince anybody responsible for that project, maybe it’s even more difficult to make codebase compliant to all of these tools. Without any doubts, static analysis has proven his usefulness, and we should be very interested in to use it. But not only one tool, but several tools at once.
I believe that not using more than one or two tools is, that we are using wrong and vague arguments and statements about static analysis. When I am listening to “there are pretty much false positives” or “these tools are checking the same things” without particular example, I am bit angry. So what are my arguments when I am talking about SA tools? In my perspective, there are five categories in which are tools distributed:
-
tools checking conventions
-
tools avoiding using bad practices
-
tools finding potential bugs
-
tools checking architectural issues
-
tools measuring code coverage
If you are an architect, lead developer, project manager or any developer interested in a project, would you like to perform checking rules enforcing code conventions, best practices, no silly technical bugs, clean architecture and good code coverage within each build of your software? Then continue reading, all you need is static analysis and tools for all the mentioned categories. This division is evident that one tool is not sufficient, and tools are complementing each other.
Convention checking tools
These tools aim to check code conventions - naming, format, and usage of comments. Rules inside are very simple and using them helps with uniform looking and consistent code. It has no impact to performance or stability, but enables people in team work together and get rid of useless discussion - typical tabs or spaces. You can guess who is the typical member of this tools in Java landscape - I will reveal on the end of the article. We need these tools aligned with code conventions of the project and always need to have a custom configuration to spare the team from the avalanche of irrelevant feedback.
Bad practices checking
Rules inside are checking well-known behaviors that systematically lead to difficulties over time, for example, dead code or long complex methods. It can be seen as a friend who is kindly reminding that developed code contains something smelling or missing (for example missing hashCode implementation when equals provided).
Finding potential bugs
There are many places in the code needed to be taken into account to spot some buggy behavior. And it’s even harder because understanding of the buggy behavior means to go through sequences of code. For example TODO my example. Also tools for Java are often working on bytecode level, so it can check things that are an almost impossible spot (or overseen) at the source level.
Architectural issues
While conventional static analysis tools are focusing on checking source code, architectural static analysis is focusing on overall architecture of the software. For example not using data access layer directly inside UI, checking usage of some framework annotations only in particular classes. I wasn’t aware about that tools for a long time. Instead, I was used to writing something internally called “Quality assurance tests” which has had one goal - for example prevent improper usage of annotations or verify that some annotation is present on the class implementing given interface. And this is what can do architectural static analysis tool specifically.
Code coverage tool
Tools are checking execution of the production code by running unit and integration tests. It checks every condition and every line of code if it were executed and provide a percentage how many code was executed to not executed. Industry standards are very questionable and are very different project to project. I have seen thresholds on 80% and 55% as well. In my opinion, there is the big mistake in using such tool - checking coverage for different kinds of the tests altogether. It’s important to have divided execution of the tests in the build process and code coverage should have different thresholds set for different groups of the test. For example for unit test, it should be close to 100%, for integration close to 80% and end-to-end test close to 50%.
What else?
I would say that critical is one more category - learning. As the tools developers write for the developers, you can benefit from using them to learn something new. Instead of treating the rules as an enemy, you need to treat them as a friend who are leading you the right direction. Every time you will have some violations, you will learn something new and you will better developer. With this comes into my mind, that static analysis is industry standard, so it’s bad if you are not having incorporated to your project.
P.S. If you enjoyed this post, you could follow me on twitter to stay in touch with my further articles and other thoughts.
P.S.2 Cover image by Johnson Wang | unsplash.com.