Why embedded-developers should use static code analysis
I decided to briefly formulate 3 reasons why embedded-developers use tools for static code analysis of programs.
fell , an error is detected, but late. Patients died , an error is found, but people will not return it. The antimissile complex begins with miss , an error has been found, but nothing pleasant in this story. Machines did not brake , mistakes are found, but there are no injuries to this pro.
The conclusion is very simple. The embedded device code should be tested as carefully as possible, especially if errors can lead to casualties or serious material losses.
Static code analysis does not guarantee that there are no errors in the code. However, you just need to use every opportunity to additionally check the correctness of the code. Static analyzers can point to a lot of various errors that manage to stay in code even after several Code-Review.
If the device, thanks to the static analysis, will be several errors less, it's great. Perhaps, thanks to the finding of these mistakes, no one will perish, or the company will not lose a lot of money or reputation because of claims from customers.
The third reason: a programmer may not know that he is doing something wrong
Errors in programs can be divided into two types. About errors of the first type the programmer knows, and they appear in the code accidentally, by inattention. Errors of the second kind arise in a situation where the programmer simply does not know that you can not write code like this. In other words, he can read this code as much as he likes, but still he will not find an error.
Static analyzers have a knowledge base about different patterns that lead to error in certain conditions. Therefore, they can tell the programmer of the error, about the existence of which he himself would hardly have guessed. An example is the use of 32-bit type time_t , which can lead to improper operation of the device after 2038 .
Another example is the undefined behavior of the program, which arises because of misuse of shift operators /. These operators are very widely used in the code of microcontrollers. Unfortunately, the programmers often use these operators extremely carelessly, making programs unreliable and dependent on the version and settings of the compiler. At the same time, the program can work for itself, but not at all because it is written correctly, but because it is lucky.
Using a static analyzer, programmers can hedge themselves against many such unpleasant situations. In addition, the analyzer can be used to control the quality of the code as a whole, which is important when the composition of the project participants is growing or changing. In other words, the analyzer helps to track whether the beginner has started writing bad code.
There is one more reason to use a static code analyzer. This is when the project must meet a certain standard of software development in the language, for example, MISRA C. However, this is rather an administrative measure, and lies slightly away from the topic under discussion.
I wanted to show that the use of a static analyzer is clearly advisable for any embedded project. Use this methodology and you will be able to:
Shorten the time to find and fix errors (
Reduce the likelihood of critical errors;
Reduce the likelihood of firmware upgrades;
To control the overall quality of the code (we recommend that you also look in the direction of ) SonarQube );
Monitor the quality of the work of new team members;
Control the quality of the code of third-party modules /libraries.
There is no reason not to use static code analysis, except laziness and illusions of superiority.
Use static code analyzers! Their a lot of .
We, naturally, offer to pay attention to our code analyzer PVS-Studio , which recently began support a number of ARM-compilers.
If you want to share this article with the English-speaking audience, then please use the link to the translation: Andrey Karpov. Why embedded developers should use static code analysis .