Static Code Analysis – Are you analyzing or debugging?

Static code analysis is not really a new development in the software world. Tools like PC Lint have been in use since the 1980s and are widely used in industry. When using such a tool, it doesn't really matter whether firmware is being developed for an embedded target or software for a PC. Nevertheless, it often seems that static code analysis hasn't yet fully arrived in the embedded sector. Many firmware developers, despite years of experience, seem to have never heard of static code analysis. Others have heard of static code analysis itself, but aren't familiar with the corresponding tools. Reason enough to provide a brief overview of the topic at this point.

Why static code analysis?

Anyone who has ever written software knows that finding errors often takes more time than writing the actual code. Many errors are already flagged by compiler warnings. Nevertheless, errors almost always remain in the code. Some of these only become apparent later in the project. These errors usually have to be found through time-consuming debugging. This can be difficult, especially with sporadically occurring errors.

The idea behind static code analysis is to automatically find errors before they even become noticeable at runtime. Every error found reduces development time. However, it should be warned that even static code analysis does not produce 100% error-free code.

Another application of static code analysis is checking code for compliance with coding guidelines. Many tools, for example, support checking according to MISRA-C rules or can be extended to include your own coding guidelines. Instead of having to fix hundreds of findings after a code review, developers can regularly review the output of the static code analysis. If this happens regularly, the programmer will eventually begin to internalize the coding guidelines and follow them automatically.

What tools are available

There are several tools for static code analysis. Many of them are available for free and fully functional. Typically, different programs are required for different programming languages. Wikipedia provides a pretty good overview here, sorted by programming language. Below, I'll discuss two tools that I've had quite good experiences with. There are probably a lot of other tools out there with similar or perhaps even better performance. They all have their advantages and disadvantages. Therefore, it may be advisable to use several tools in parallel. This is even recommended by some software developers.

PC Lint

When it comes to commercial tools for analyzing C code, I personally have good experiences with the classic PC Lint The tool offers a wide range of features and is highly configurable. It includes, among other things, the MISRA-C rules. Each MISRA-C rule can be selectively activated or deactivated. This also applies to any other rule according to the Lint checked the code. In addition, Lint There are various ways to integrate your own rules. For example, you can use the command -deprecate  for keywords such as goto For each goto the Lint If a rule is found, a warning specified by the developer can be issued. By selectively enabling and disabling rules and implementing new ones, you can largely integrate your own coding guidelines.

The high complexity of Lint However, this is also the biggest disadvantage. It takes some time to get used to Lint really warmed up. If you have no experience with the tool and want to set it up for a new software project, it will take quite a while until the program really works smoothly with all the desired rules. Especially since the tool's documentation is not very clear. In addition, Lint It has no GUI, but is a pure command-line tool by design. Developers can significantly improve the workflow by writing programs in scripting languages such as Python. These can automatically adapt the Lint configuration to their own software project (for example, setting the include paths) and linten of all files. Of course, writing these scripts can also be time-consuming.

Cppcheck

One free alternative for analyzing C code is the program Cppcheck. Its biggest advantage is its ease of use. Once the program is installed, you can set up a new Cppcheck project in just a few minutes. The integrated GUI is very simple and intuitive, so reading documentation is actually unnecessary. This open source tool also finds many errors and checks the code according to certain style rules. The software distinguishes between four levels of output: error, warning, style warning, and information. Each level can be switched on and off separately. Due to its ease of use, Cppcheck is definitely a good choice for developers who want to check existing code for overlooked errors without much effort. However, you should limit yourself to warnings and errors here, as otherwise the effort required to examine the output can become very time-consuming.

Pitfalls

The worst thing you can do when using static code analysis is to finish developing your firmware and then "quickly run the tool over it again to see what it finds." This means that many errors have probably already been found through time-consuming processes such as debugging, which could have been found much more quickly using static code analysis. On the other hand, depending on the configuration of the tool used, the developer may be overwhelmed by the sheer number of errors, warnings, and information found. This happens especially when coding standards such as MISRA-C are required and are to be checked using static code analysis. If the developer then runs static code analysis at the end of development, hundreds of warnings per module can occur. Often, this is simply because one or two rules were overlooked during development. For an entire firmware project, this can quickly lead to thousands of outputs.

Of course, it's usually still a good idea to examine a finished piece of software using static code analysis. However, you should limit yourself to "real" errors. Tools like Cppcheck or PC Lint usually allow you to configure different levels of warnings. PC Lint For example, distinguish between errors, warnings, and information, each of which can be enabled or disabled. However, if possible, it is recommended to use static code analysis tools as early as possible. Ideally, the tools should be set up right at the beginning of a firmware project and used regularly. Automation can also be useful. For example, many tools can be integrated into the compiler's prebuild process or into a version control tool.

Conclusion

In my opinion, there is no reason not to use a tool for static code analysis. Even if you think that your compiler already finds most errors, free tools like the one mentioned above are already Cppcheck far too simple to use to simply ignore. Every additional tool at least slightly increases the probability of discovering errors in your own code that would otherwise have to be laboriously searched for manually, or that might otherwise remain unnoticed in the code. More complex tools may require a certain amount of time to set up initially, but it should be noted that every error discovered early on naturally saves time. If you take the time to set up a tool for one project, you can then use the corresponding configuration for every subsequent project anyway. For software developers, it is therefore always worthwhile to familiarize themselves with the topic and try out different tools. If only because the style warnings that appear in abundance at the beginning and are sometimes very annoying, inevitably lead to a better programming style.

I would be very happy to receive feedback and additions, such as recommendations for additional tools and techniques.