Static and dynamic code analysis: Complementary techniques (original) (raw)

While every programmer wants to deliver high-performing, secure, bug-free and compliant code on the first try, that's not possible. Effective code analysis techniques will help.

If you ask development teams what their primary goal is, the three most common answers will likely include:

So, how can teams review code to make sure that the three primary goals are met?

Code analysis is the easy answer to the question, but should it be static code analysis? What about dynamic code analysis? Or maybe both?

Let's examine how static and dynamic code analysis play an important role in development and how their differences help shape code.

How do static and dynamic code analysis differ?

Static code analysis examines code to identify issues within the logic and techniques. Dynamic code analysis involves running code and examining the outcome, which also entails testing possible execution paths of the code.

Even in the most rudimentary fashion, when development teams test the code, they're performing dynamic analysis. And when programmers review the code, they're performing static analysis. Regardless of which tools they use, developers and programmers are performing analysis that ultimately helps create better code.

Neither static code nor dynamic code by itself is the ideal option, which means that teams should optimize both. Development teams can't think of static and dynamic code analysis as alternatives. View them instead as complementary and symbiotic.

Code review is similar to static analysis

If, for some reason, a team decides it wants to omit static code analysis, that really means it plans to not review the code. Think of code review and static code analysis as related terms. Code review helps find code issues without committing to expensive and time-consuming dynamic tests. Static code analysis, done in a code-review context, is the first and most essential step in developing and maintaining good software.

Static code analysis, done in a code-review context, is the first and most essential step in developing and maintaining good software.

Most static code analysis is done with tools designed to evaluate the code and look for errors or non-recommended techniques and practices. Organizations who treat static code analysis as an element of code review will likely conduct formal code reviews first, then apply the static code analysis tools and finally review the results through the code review process of choice.

If an organization decides to first review the code with a programmer and mentor, they might consider using static code analysis first. This approach will likely catch at least 85% of code errors and save the expert valuable time in identifying them.

Static code analysis and review is particularly well-suited to rapid development and GitOps environments, where changes are often made to a single component. For example, if the software design properly isolated component behaviors, static analysis will catch most of the code errors.

So why dynamic analysis?

Simply put, static analysis doesn't catch every code defect.

It is particularly limited when it comes to addressing issues in complex, multi-component applications. It also provides little to no value when you want to measure performance or test policies for scaling and/or load balancing. These limitations are where dynamic code analysis comes into play.

Coordinate dynamic and static analysis

Just as development teams already use static code analysis routinely -- even if it's not formally mandated or managed -- they also use dynamic code analysis. Routine software testing and running software to verify a fix or validate the initial implementation are forms of dynamic code analysis.

So, it's not a matter of static code analysis vs. dynamic code analysis. Teams likely already use both. The question becomes how to use both effectively.

Static code analysis is best paired with code review. Dynamic code analysis is suited to some form of automated testing and test data generation.

Teams should focus dynamic code analysis first on the area where static analysis is likely to be ineffective, such as component performance, application performance, application logic, security validation and crossing component boundaries. For example, automated test data generation tools such as Redgate SQL Data Generator and DTM Data Generator (to name just a few) will simulate an application's operation at full load, validate all the logic paths and test whether these points could have security vulnerabilities. An organization may already use these tools, but it's important that they're testing the specific areas that static analysis is most likely to miss.

It's easy to automate performance and load testing with widely available tools and practices. Logic and security validation are more difficult to set up with any form of generated-data automated testing. Teams will need to emphasize test design and carefully choose data generation tools with specific, per-field value constraints to run tests that identify potential issues. On the security validation front, teams should extend test data range values beyond normal operation to ensure they won't create potential problem areas.

The static and dynamic code analysis debate is an indicator of a fault in many development strategies that look more at individual steps instead of the overall process. Both static and dynamic code analysis have important roles to play as part of an integrated development and deployment process. Without each other, neither are likely to serve you well.

Dig Deeper on Software design and development