You are here

You are here

4 types of code analysis every developer should embrace

Stephen Magill CEO, MuseDev

You often hear the term "static analysis" used as if it refers to a single, known tool or technique, as in, "We make sure all our code goes through static analysis before being released." But the type of static analysis you use matters.

The most commonly referenced type is called SAST (static application security testing), which is considered a best practice in app sec testing. But you can also use static analysis outside of security. Covering all of these error classes often means using multiple tools, since different tools tend to catch different types of errors.

Here are four types of code analysis types you should know about, and each has benefits for your software development team.


Static analysis tools can help to catch common coding patterns that lead to poor performance. For example, ErrorProne's BoxedPrimitiveConstructor rule looks for patterns such as "new Boolean(true)," which was common practice in older versions of Java but has now been deprecated in favor of more efficient methods.

Using static analysis tools to catch these performance anti-patterns ensures that they won't sneak into your codebase. But these tools also provide an important educational benefit: They show seasoned developers that best practices have changed and show new developers that there’s a better way to accomplish a given task.


Issues such as null pointer exceptions in Java or resource leaks in C do not typically affect security. But they are nonetheless important issues to track and correct, since these problems can lead to unexpected behavior or downtime.

No one wants to receive that 3 a.m. pager message that the service is down; static analysis tools focused on reliability can help prevent that. For example, Facebook's Infer tool can discover null pointer issues, memory leaks, and thread safety/synchronization issues.

Since memory leaks and threading issues are notoriously hard to find and debug, static tools can be especially useful for these error types, saving developer time and boosting productivity in the long run.


There are a broad range of security issues, and this is matched by a range of different static analysis algorithms designed to catch them. For example, techniques focused on finding information flow vulnerabilities (which underlie OWASP Top Ten issues 1, 3, and 7), are not necessarily good at finding memory safety issues (SANS 25 Issue #1).

This means it's a good idea to use multiple tools even if you primarily care about security. 

Facebook's Infer tool, mentioned above, can help catch information flow vulnerabilities such as command injection attacks or failures to encrypt data at rest. Configuring Infer to provide knowledge of your application and frameworks can help catch more errors and improve the signal-to-noise ratio.

The open-source tool FindSecBugs can catch configuration issues, uses of weak cryptography, and framework-specific command injection issues. It works right out of the box—no configuration required.


Another best practice is to encourage developers to adopt a uniform coding style across the team. The question of what style to use is not as important as ensuring that developers follow a consistent style. Examples of these are Airbnb's open-source style guides.

There are two great reasons to automate detection of style violations using static analysis. First, automation ensures that style rules are never violated and helps keep your code consistent. Second, if a tool is pointing out style violations, then a developer doesn't have to.

No one wants to be the code reviewer pointing out six different spacing or variable naming issues. It's better to let the tools take the blame for being pedantic so that human team members can focus on suggesting meaningful improvements to architecture, abstractions, and other higher-level aspects of code quality.

Get integrated

With so many tools necessary to achieve broad coverage across a wide range of error types, integration of tools into DevOps processes is particularly important. Multiple tools can be made seamless and lightweight if they are integrated in a consistent manner. (For more tips on effective integration of static analysis tools, see this article on best practices from Google and Facebook.)

Most important, find the right point to target in your development workflow. Code review makes a particularly attractive target because the platform is shared across developers (compared to IDEs, which tend to be more fragmented) and is often centrally managed.

To take steps toward broadening your use of static analysis, start with FindSecBugs and PMD, which cover security and style issues and are very easy to integrate. Infer and ErrorProne require build system integration, but also provide much deeper analysis. Given the productivity improvements and confidence these tools provide, finding a way to incorporate them all is well worth the investment.

Want to know more? Attend Stephen Magill's conference session at DevOps Enterprise Summit London—Virtual, where he'll offer more tips on the role of code analysis in your pipeline. The conference runs from June 23-25, 2020.

Keep learning