An article about static code analysis for managers that should not be read by programmers.

If you consider yourself a good programmer, well, let's say, you rate your level above average, please do not read this article. This article is intended for software project managers. I want to discuss with them, although important, but boring for programmers questions related to the methodology of static code analysis.

I hope the introduction has scared away at least some programmers from reading. Someone, probably, from the principle continued reading, but well, it is their voluntary choice. We will talk about things that are unpleasant for programmers.

Our company is developing a PVS-Studio analyzer intended for finding errors in the code of programs in C, C ++ and C #. The idea is simple: we run the analyzer regularly and study parts of the code that seemed suspicious to him. In general, a kind of automatic code-review .

Any manager, and the programmers themselves, understand that high-quality code is better than low-quality code. It is also clear that the less glitches appear in the program, the better.
')
The most interesting begins further. Although everyone recognizes the importance of high-quality code, some programmers simply become indignant when they are offered to use static code analysis. It seems that they were insulted by doubting their professionalism, and they are in a hurry to respond with the whole arsenal of their negative criticism. Over the years we have heard a huge amount of unflattering comments, of the following content:

• “This is a tool for McDonalds, and our team employs experts, and if we have errors, they are associated only with the synchronization of flows”
• "We do not use static code analysis, as we recruit only above-average professionals"

I think if at the time of such discussions a project manager was present nearby, then quite a few programmers would get a click on him for pride. Each manager can remember how several days they were looking for a mistake, which later turned out to be some kind of silly typo. Or the manager may begin to overcome skepticism: if everything is so good, why does the application continue to fall from time to time? Managers are not as optimistic as programmers are to the project development process and emerging issues.

Figure 1. Programmers are often too optimistic, being sure that everything is fine.

Therefore, I want to reveal to managers the secret, which in fact, of course, is no secret. Programmers have a problem with revaluation of their level. About this is well written in the article " Programmers 'above average' " ( en ). I will quote the passage:

How do you rate your level as a programmer (below average, average, above average)?

According to psychological surveys among different groups , about 90% of programmers answer "Above average".

Obviously, this cannot be true. In a group of 100 people, 50 will always be higher and 50 - below the average. This effect is known as the illusion of superiority . It is described in many areas, but even if you have heard about it, you still probably answer "above average" .

This is a problem that prevents programmers from mastering new technologies and methodologies. In our case, it interferes with a positive attitude towards static code analysis. It's unpleasant for a programmer to realize that some program will teach him how to write code better. And it’s quite unpleasant when the analyzer detects stupid errors in its ideal code, and makes them public domain. It takes great willpower and wisdom to notice and accept its shortcomings and flaws. It is much easier to give a negative review about the tool or about a technology in general, and stay to live in your cozy closed world.

PVS-Studio analyzer finds errors in the code of such projects as Qt, MSBuild, LLVM, GCC, GDB, Chromium. The developers of these projects can not be rated below average. However, this does not prevent all new and new programmers from responding that their code is high-quality and for them the analysis of the code is not relevant. In such cases, I like to ask: since everything is so good and all such professionals, who made these 11000 mistakes ? The question, of course, is rhetorical, and I do not expect an answer.

I think managers understand what I'm getting at. Static analysis is extremely important and useful in the development of medium and large projects. It helps to deal with many errors and allows you to control the quality of the development process as a whole. Regular checks will allow time to identify an abnormal increase in the number of errors, for example, due to the fact that someone was going to quit and govododit, since he does not care, but you need to create the appearance of work. Of course, I came up with this situation, but it is really useful to have a tool that can assess how well everything is with the project, and the number of analyzer warnings is one of the best metrics for it.

By the way, on this subject I will tell something interesting. Recently, a colleague checked the project CryEngine V. Bug on a bug. A colleague did not even look through the warnings of the High level, there are too many of them. And then we suddenly find out that lately, Crytek has problems and some programmers have not been paid for 3 months. The unhealthy situation in the company affected the quality of the code. It was interesting to see such a clear relationship.

In general, you should feel free to force programmers to use static code analysis. Even if not PVS-Studio, let it be at least Cppcheck (it performs simple checks, but it is free). This will be a big good thing. The programmer, of course, can be capricious, therefore it is worthwhile to show firmness.

Often, programmers refer to the fact that working with the analyzer takes time, forcing to view false warnings.

Here I will not restrain from sarcasm: Yes, yes ... Spending one day on setting up the analyzer to reduce the number of false positives is a lot. And to sit and look for a week for a mistake, this is just right, this is normal.

Proof : an error, the detection of which was unsuccessfully spent about 50 hours, with a single launch of the analyzer was detected and corrected in less than an hour.

By the way, if there is no need to start with finding errors in the old code, then it is very easy to integrate a static analyzer into the development process. PVS-Studio can only show errors related to new or modified code (see mass analyzer message suppression ).

Should be skeptical about the objections of programmers on why they do not need a static analyzer. They may not really need it. He needs a project. This is one of the methodologies, such as, for example, unit tests, which allows you to increase the reliability of the program and, thus, reduce the costs of its maintenance. The faster some errors are found, the better. Static analyzers make it possible to detect errors at an early stage, i.e. as soon as they appear in the code.

Figure 2. Note that some programmers use static analysis incorrectly.

Another important point. Some programmers may state that little was found during the test run, so the introduction of a code analyzer is not practical. Do not let them confuse you. Of course, there will be few errors in the debugged and working code, otherwise the program would not work. However, finding and fixing errors can be very expensive. Often, many user complaints and hours of meditation by programmers in a debugger could simply disappear, thanks to a single launch of the code analyzer. All essence and advantage of static analysis in its regular use, and not one-time launches.

Several times I myself have heard that some programmers launch static analyzers in preparation for release. If someone does this and claims that this is normal, then he is unprofitable. This is the wrong way to use static analyzers. This is the same as enabling the compiler warnings before the release, and working on the project the rest of the time, turning them off completely.

Thanks for attention. I invite everyone who is interested in the methodology of static analysis in general and the PVS-Studio analyzer in particular, to write to us . We will help check your project, configure the analyzer, and show you how to deal with the issued warnings.


If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. Not recommended for the programmers