Static analysis tools refer to a wide array of tools that examine source code, executables, or even documentation, to find problems before they happen; without actually running the code.
These tools vary greatly in scope and purpose, ranging from compiler-level checks for logical errors, to code styling enforcement, to cloud-based suites of tools that cover everything from documentation formatting to code complexity analysis.
Put simply, you could think of static analysis tools as anything that helps you maintain a healthy code base without having to actually run that code.
Why are they useful to you?
How can static analysis tools improve our product?
Ultimately, we want to build and ship successful features/tools/products/etc. This requires effort, time, and money.
In the short term, we may choose to accept technical debt, smelly code, and bad practices.
However, eventually all of those things catch up to us. Tech debt, smelly code, and emergent bugs slow down the development cycle, reduce product quality and ultimately increase the amount of effort, time, and money required to build a product.
Static analysis tools can help us reduce and avoid these issues all-together by making it easier to find & fix these issues before they have significant impact on our projects.
How can static analysis tools improve code quality?
They can enforce coding standards and analyze dependency graphs.
They can analyze control flow, nesting, and data flow as well as the complexity of blocks, functions, classes, files, etc.
There are tools to analyze requirements docs or code documentation.
They can be used to reformat code or to measure test coverage.
These things mostly seem small when considered in isolation, but if ignored, our code quality will likely slowly degrade over time.
With the right tools, we can analyze and optimize our code with less effort. This makes the process more efficient, and therefore, more likely to continue over the lifetime of our projects.
If our code is constantly evaluated by a tool in the same way every time, our teams may also learn how to write code with fewer issues.
Static analysis tools can improve the initial quality of our code which may reduce the number of issues the tools need to catch. Through this iterative process the codebase can continue to improve.
In a perfect world, we would write issue-free code to begin with. Certainly we do NOT live in a perfect world, and bug-free code is a dream, but if we are consistently analyzing our code, fixing those issues, and learning from the process then we can continue to write more effective code.
Why do we need tools for these things?
The simple answer is, “you don’t.”
A big part of growing as a software engineer is learning to analyze our own code and to make many of the same considerations that have been mentioned above. We could skip any kind of tooling and enforce “code analysis” during code review.
However, building software is so much more than just the code, and yet we only have so much time in the day and so much brain power to go around. Looking for, and enforcing all of these different code quality items by hand will greatly slow down the code review process and make it a burden rather than a great learning opportunity.
“automate as much as possible”
Integrating static analysis into our development process and/or build pipeline frees us from the burden of manually performing analysis that can be automated.
There is no need to enforce code styles by manually commenting on every line in a PR. Analyzing code complexity can be time consuming and difficult for a developer. A tool can perform the same analysis, with the same attention to detail every time, every day.
Relying on static analysis tools also removes the human element from possibly frustrating parts of the review process such as nit-picky styling or convention errors.
If a tool is pointing out deviations from an agreed upon style, there is no need for a back and forth between team members. There is no bias. The tool is not in a bad mood and commenting on every little thing. Either the tooling succeeds or it doesn’t.
Less time discussing and debating small items in a review leaves additional time for more interesting and important conversation.
Things that tools do well, might not be done at all if it’s the sole responsibility of the developer.
Protect your code reviews and automate as much as possible.
How can you use them?
There are an overwhelming number of static analysis tools & platforms out there ranging from generalist, multi-platform tools to more specific tools for a single platform or language.
Integrating each tools will be a bit different, but nearly all may be run from the command line. Many will be built into, or integrate with, your favorite IDE, and most can be integrated into your continuous integration workflows so the tools may be run consistently for everyone on a project.
Here are just a few examples of different static analysis tools:
Like I said previously, there are an overwhelming number of static analysis tools out there. If you’re looking for something specific, there is a very comprehensive list available on Wikipedia and other great list here on GitHub.
Hopefully this has shed some light on what “static code analysis” tools are and why you might want to take a closer look at using them in your projects.
This is the first part in a series of posts that will dive deeper into static analysis tools for Android projects, so stay tuned for future posts.
If you’re looking for more on this topic, I’ll also be posting companion videos to my YouTube channel and you can have a peak there and/or subscribe to the channel for future updates.