An article on static code analysis for managers that programmers should not read

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

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

Our company is developing the PVS-Studio analyzer, designed to search for errors in the code of programs in C, C ++ and C #. The idea is simple: we run the analyzer regularly and examine sections of the code that seemed suspicious to him. In general, a certain analogue of the automatic code-review .

It is clear to any manager, and to the programmers themselves, that high-quality code is better than low-quality. It is also clear that the less glitches appear in the program, the better.

The fun begins next. While everyone recognizes the importance of quality code, some programmers are simply outraged when they are asked to use static code analysis. It seems that they were insulted, doubting their professionalism, and they are in a hurry to answer with all the arsenal of their negative criticism. Over the years, we have heard a huge number of unflattering reviews, approximately of the following content:

• “This is a tool for McDonald’s, and experts work in our team, and if we have errors, they are only associated with thread synchronization”
• “We do not use static code analysis, as we only recruit professionals above the average”

I think that if at the time of such discussions a project manager was present nearby, then a lot of programmers would get a click for pride from him. Each leader can remember how they searched for a mistake for several days, which later turned out to be some kind of silly typo. Or the manager may begin to be skeptical: if everything is so all right, why does the application continue to crash from time to time? Managers are not as rosy as programmers are regarding the project development process and emerging issues.

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

Therefore, I want to reveal to managers a secret, which in fact, of course, is no secret. Programmers have a problem re-evaluating their level. This is well written in the article " Programmers 'Above Average' " ( en ). To quote a 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 will be below average. This effect is known as the illusion of superiority.. It is described in many areas, but even if you heard about it, you will probably still 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 to static code analysis. It is unpleasant for a programmer to realize that some program will teach him how to write code better. And it’s really unpleasant when the analyzer detects stupid errors in its ideal code and makes them public. It takes a lot of willpower and wisdom to notice and accept your weaknesses and shortcomings. It is much easier to give a negative review about an instrument or about a technology in general, and stay in your comfortable, closed world.

PVS-Studio analyzer finds errorsin the code of such projects as Qt, MSBuild, LLVM, GCC, GDB, Chromium. The developers of these projects cannot be rated below average. However, this does not prevent newer and newer programmers from answering that their code is high-quality and code analysis is not relevant for them. In such cases, I like to ask: since everything is so good around and all such professionals, then who made these 11,000 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 you to timely identify an abnormal increase in the number of errors, associated, for example, with the fact that someone was going to quit and shit, since he doesn’t care anymore, but he needs to create the appearance of work. Of course, I came up with this situation, but it’s really useful to have a tool that can evaluate how good the project is and the number of analyzer warnings is one of the best metrics for this.

By the way, I’ll tell you something interesting on this topic. Recently, a colleague checkedCryEngine V. project. Bug on a bug. A colleague didn’t even watch the High warning, there are a lot of them. And then we suddenly find out that recently Crytek has problems and some programmers have not received a salary for 3 months now. An unhealthy situation in the company affected the quality of the code. It was interesting to see such a clear relationship.

In general, you should not be shy to force programmers to use static code analysis. Even if not PVS-Studio, even if it will be at least Cppcheck (it performs simple checks, but it’s free). This will already be a great good deal. The programmer, of course, can be capricious, so it’s worth it to show firmness.

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

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

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

By the way, if there is no need to start by finding errors in the old code, then integrating a static analyzer into the development process is very simple. PVS-Studio can only display errors related to new or changed code (see mass suppression of analyzer messages ).

You should be skeptical about the objections of programmers on why they do not need a static analyzer. They may not really need him. The project needs him. This is one of the methodologies, the same as, for example, unit tests, which allows you to increase the reliability of the program and, thereby, reduce the cost of its maintenance. The sooner any errors are found, the better. Static analyzers can 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 claim that few errors were found during the test run, so implementing a code analyzer is not practical. Do not let them confuse yourself. Of course, there will be few errors in debugged and working code, otherwise the program would not work. However, troubleshooting can be very expensive. Often, many user complaints and hours of programmer meditation in the debugger could simply disappear, thanks to a single run of the code analyzer. The whole point and benefit of static analysis is its regular use, and not one-time launches.

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

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

If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. A post about static analysis for project managers, not recommended for the programmers