Get the latest critical update information for Log4j vulnerability. See how to address the issue with Parasoft guidance. Learn More >>
As any coder and quality assurance tester will tell you, static analysis is a critical part of workflow. In the same way that vaccines require multiple trials, any project requires code quality analysis on multiple fronts.
To that end, Parasoft provides static analysis tools to help automate the process. This also augments best practices to become more agile in response to necessary changes and updates. But having a foundational understanding of static analysis, its tool, and the best practices is critical fundamental knowledge.
Educate or re-familiarize yourself with these concepts here. This blog answers the following questions:
Simply speaking, the process of static code analysis identifies defects and errors in source code. While the analysis can be automated, code reviewing is generally a joint effort on behalf of developers and QA/QC testers alike.
But static analysis allows for more immediate remediation and is integral to the development process. Regardless of industry, function, or language, static analysis remains a foundational part of any development workflow.
Performing static analysis requires a simple set of steps.
But the best thing about static analysis is that it does not require code execution. All one has to do is run the analysis to identify problems to be fixed without undue risks.
The general best practice around when to perform static analysis is before code review and after the code has been written. Auditing the source code at that stage reduces wasted time by resolving errors more quickly.
One of the most common types of static code analysis is SAST or static application security testing. This is also considered a best practice for application security testing, but can be applied elsewhere. In order to identify all error classes, multiple coding standards (MISRA, AUTOSAR, CERT, CWE, etc.) may need to be used.
As such, it’s best to familiarize yourself with various types of static code analysis and the errors they’re meant to detect.
These methods are some of the most essential when it comes to code quality testing. Engineers may inadvertently cause crashes or memory corruptions with a mistake. Pattern-based static analysis roots out the causes of these problems by patterns in the code that may be errors.
This can be as simple as syntax checkers to something more sophisticated. Another note: these static analysis tests rarely return false positives.
This method reviews code for problematic constructions in a ruleset by simulating decision paths. Use it to find buffer overflows, null pointer dereferences, tainted data, and the like.
Though a less complex test, metrics analysis helps to measure the characteristics of code. This includes code complexity, maintainability, testability, and more.
Each static analysis rule or guideline tackles different issues. Some issues that affect reliability might be resource leaks for C or null pointer exceptions in C++. MISRA C:2012 Directive 4.12 exists to prevent the use of dynamic memory that can lead to out-of-storage run-time failures, which is undesirable.
The guideline states, “The identifiers ‘calloc’, ‘malloc’, ‘realloc’, ‘aligned_alloc’ and ‘free’ shall not be used and no macro with one of these names shall be expanded.” Therefore, the following code will produce a violation.
int* p1 = (int*)malloc(10); /* Violation */ free(p1); /* Violation */
The recommended solution is to pre-allocate a block of memory and manage it as needed by way of your own defined equivalent of “malloc” and “free”. Similarly in C++, the common solution is to overload the “new” and “delete” operators.
The intent of the software, the language, and the platform all affect the kinds of errors static code analysis can detect.
There are a few myths to dispel before getting into static code analysis best practices. For instance, static analyzers are not single-use products nor is dynamic analysis better or worse than static analysis.
But in general, there are concrete best practices along with emerging best practices developers should adopt when it comes to static analysis for code quality.
Writing code with all of these things in mind ensures fewer errors overall. But in tandem with static code analysis, it further simplifies the bug identification and QA/QC process.
As mentioned earlier, static code analysis identifies errors based on given rulesets. That means that, if any line defies a rule, it will be flagged. Of course, as in real life, there are some exceptions to these rules across different software types.
In situations like these, developers allow for deviations. The rules can adjust to the circumstances and allow for special issues. A team can decide yes or no on whether or not that deviation is acceptable. This also gets documented as it violates the original rules.
Static analysis is what it sounds like: an isolated review of the source code. Dynamic analysis, on the other hand, tests code as it is executed on a virtual or even a real machine/processor.
Think of static analysis as a brush here and dynamic analysis as a fine-toothed comb. It can identify more subtle defects since it reviews how code interacts with other systems, sensors, or peripherals.
The big difference is that dynamic analysis cannot find flaws in an entire codebase. It can only find issues in excerpts of executed code. Another best practice is to make use of both static and dynamic analysis test methods to produce the most effective and efficient code.
Parasoft’s suite of tools to automate software testing works across diverse workflows and team compositions. When it comes to static code analysis, that rings just as true. Doing so can speed up the development cycle, reduce defect rates, and provide continuous improvement. Identifying which tool might work best for your needs starts simply with the base language of the source code.
Not only do we provide C/C++ solutions, but Parasoft also supports Java with Jtest and the .NET language with dotTEST. Why stay stuck doing more work than you have to when you can speed up the process and get enhanced results?
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
A Sr. Technical Product Marketing Manager for Parasoft’s embedded testing solutions, Ricardo has expertise in the SDLC and test automation of embedded real time, safety, and security-critical applications, and software compliance to industry standards.