This article series is in the Improving Software Code Quality topic within our Series Library
Though many tweaks can be done to development processes to speed your certification, everything starts with code quality. But how can you ensure code quality? Fortunately, there are some easy ways to almost instantly upgrade your code-quality game with as little pain as possible.
Get Help from Standards
Did you know that in C99, about 190 different ambiguities exist in the code specification? What we mean is that in C99, 190 different syntactically legal C constructs aren’t spelled out in the C language specification. It actually gets a bit worse when you go to C18 and even more so in C++, where you start introducing concepts of multiple and virtual inheritance. Of course, a compiler must turn source into concrete code, so it has to pick an interpretation of what your code means and run with it.
Practically, this means that different compilers can interpret your source code differently. In a high-reliability system, this is a nightmare scenario, especially since many companies pursuing functional safety-certification are cross-compiling their code on multiple platforms for ease of testing. As you can imagine, this could have a detrimental impact on the time it takes to get your certification because you must test around all of these situations to prove the repeatability and reliability of the code.
How do we get through this? The short answer is that you avoid these ambiguities in your code. But how do we do that? Using coding standards like MISRA is a quick way to solve the problem because they’re designed to prevent those types of common pitfalls in code. They also promote safe and reliable coding practices to reduce the number of defects in the code. But how can we make sure we follow those standards? Fortunately, functional-safety standards give us a way to accomplish the task.
Standards Require Code Analysis
Virtually every functional-safety standard requires that you do static analysis of your code, and highly recommends that you do runtime (or dynamic) analysis of your code. The most broad-reaching of these standards is IEC 61508, which covers safety-related systems in general.
In section C.4.2 of that standard, using C without coding standards that remove ambiguous and dangerous behavior isn’t recommended for anything above Safety Integrity Level (SIL) 1. In other words, you must use static analysis to make your code more robust if you’re looking to get SIL 2-4 certification for your product. Why is this? These static-analysis tools can force a developer to implement coding standards like MISRA. Moreover, static and runtime analysis helps you to up your code-quality game by quickly pointing out when you’re getting into risky coding behavior, especially with the aforementioned coding standard ambiguities.
However, these types of automated tools can also have a huge impact on your certification timeline. Many organizations employ hard-to-configure, hard-to-use code-analysis tools that are relegated to running on a build server as part of a nightly build.
Such a scenario doesn’t really help much because the individual developer isn’t getting instantaneous feedback on what’s wrong with the code they just wrote. Moreover, sometimes the warning messages that come from these tools are inscrutable. Thus, the developer wastes time trying to figure out what they mean and how the code can be corrected to make the warning go away.
If you can run code analysis during development—and before you check it into a formal build—then it’s like the defect never even happened. You get a lower defect injection rate for your project that certification entities love to see, because it means you have a very mature development organization.
Making Code Analysis Part of the Daily Workflow
The easier code-analysis tools are to configure and use, the more likely and quickly developers are to use them and realize the benefits. Having these automated tools as part of the developer’s toolbox means that you can check and improve the code quality as you write your application, while you’re “in the zone” of understanding what that section of code is meant to do and how it interacts with other modules in the system. To do this effectively, the tools must be integrated into the daily workflow.
When looking through what others are saying in regards to integrated code analysis, I found that Google published an article, "Lessons from Building Static Analysis Tools at Google," in Communications of the ACM, looking at the merits of code analysis. Though the article takes a holistic view of their entire codebase including C, C++, and Java, their results are very clear:
“Compiler errors are displayed early in the development process and integrated into the developer workflow. We have found expanding the set of compiler checks to be effective for improving code quality at Google.”
The authors stated that moving static-analysis checks into the compiler workflow and making them appear as errors drastically improved the attention paid to the tool’s findings, and that it ultimately meant that their code was of a much higher quality. Further on, they talk about a survey sent to developers who recently encountered a compiler error and developers who had received a patch with a fix for the same problem:
"Google developers perceive that issues flagged at compile time (as opposed to patches for checked-in code) catch more important bugs; for example, survey participants deemed 74% of the issues flagged at compile time as ‘real problems,’ compared to 21% of those found in checked-in code."
The article also talks about the importance of having code analysis part of the workflow by stating that when they automatically ran commits through a static analysis tool and invited engineers to look at the analysis dashboard, very few engineers followed through. Having instant feedback in the compilation process made static analysis easier to use and harder to ignore. Therefore, they chose to integrate static analysis by default in everyone’s workflow. They believe that for code analysis tools to succeed, developers must feel they benefit from their use and enjoy using the tools.
But what kind of results can you expect to see from adding code analysis to your workflow? One thing is an improvement in the overall security of your application—having high code quality can eliminate exploits like buffer overflows, illegal pointers, and the like, as described in the article, “Improving Software Assurance through Static Analysis Tool Expositions.”
While this in and of itself is a compelling reason to use code analysis, it’s sometimes hard to convince people of the maxim that “an ounce of prevention is worth a pound of cure.” You often need even more significant results to convince developers and management alike of the merits of code analysis.
A paper by Stefan Wagner and others used empirical data to calculate the benefit of code-analysis tools vs. traditional testing on different code bases. Their results are very telling: Out of the 769 identified defects, 76% were caught by code-analysis tools and only 4% by traditional testing (the remaining 20% found by code review).
How fast could you achieve your mean-time-to-failure (MTTF) goal in software if you could eliminate 75% of your bugs before you even begin testing? The answer is “awfully quick.” The time and money savings on testing alone make the investment in code-analysis tools worthwhile, not to mention the savings in time to market. These are the types of processes that functional-safety certification entities love to see because it drastically reduces the risk of defects making it into the field in your final product.
High-Quality Code Speeds Your Path to Functional Safety
The key to accelerating the functional-safety certification process is to improve your code quality. By improving code quality, you lower your defect injection rate, which means you more quickly reach the software release criteria. Thus, your development organization looks very mature to a functional safety-certification entity. While you can never know exactly how many defects are left in an application, you can minimize the number by using code-analysis tools early and often.
Read more from the Improving Software Code Quality series within our Series Library
Shawn Prestridge is the U.S. Field Applications Engineer Team Leader for IAR Systems.