Static Analysis—what's it good for?

Let’s face it, writing software is hard. And frankly we humans suck at it. We need all the help we can get. Our industry has developed many tools and techniques over the years to provide “safety rails”, from the invention of the macro assembler through to sophisticated integration and automated testing frameworks. But somewhere along the way the idea of static analysis went out of favour.

I’m here to convince you that static analysis tools still have a place in modern software engineering.

Note that I am avoiding the word “metrics” here. That is how a lot of people think of these tools, and the whole idea of “measuring” a developer’s work rightly has a terrible reputation (“what does that number even mean?”). Static analysis is simply about providing information that a human can use to learn more about a code base.

What is static analysis?

Simply, it’s a tool that analyses your code “at rest”. That is, it inspects the source code (or in some cases object code) statically, not in a running environment. (Dynamic analysis of running systems, such as with memory profilers like yourkit and valgrind, is a whole other topic.)

Why is it so unpopular?

One of our developers recently made the following comment in an internal chat channel:

After seeing some refactoring that people have done to satisfy static code quality analysis tools, I question their value.

This is a common response to the use of such tools, and perfectly reasonable. But it misses the point. Of course static analysis can be misused, but that doesn’t mean it has to be.

Another common complaint is “but these tools can’t replace the eye of an experienced developer!”. No, they can’t. But they can help focus that experienced eye where it is most needed.

So what is it good for?

The static analysis tool itself is not going to tell you any of these things, but it might suggest places to look for potential trouble.

What is it NOT good for?

How should I use my analysis tools?

Quality is a people problem

“It is impossible to do a true control test in software development, but I feel the success that we have had with code analysis has been clear enough that I will say plainly it is irresponsible to not use it.” – John Carmack, In-Depth: Static Code Analysis

No tool is going to be a silver bullet. Software quality is and always has been primarily a “people problem”. Tools can help, but they cannot automatically fix all your problems and enforce all your “rules”. They simply provide information that can help people focus on the areas most needing attention, and highlight potential problems that might otherwised have been missed.

Static analysis tools (aka “quality metrics”) can be a useful way to gain more insight into your code and identify areas that need more attention.

(This article was originally published on the REA Tech Blog.)