The philosophy of static code analysis: we have 100 programmers, the analyzer found few errors, is it useless?

People very often think about static code analysis.



You can often find such an opinion, expressed in the following paragraph:



We have a big project. It employs several dozen (hundreds) of programmers. That is, the one about which you write that you need a static analysis. I downloaded the code analyzer, ran the check, and found very few errors. Obviously, the code analyzer is just useless!



Alas, but it seems that the way to promote static code analysis through the idea of ​​checking open source projects plays a cruel joke with people. People EXPECT that by running the analyzer on a random project, they MUST find a bunch of errors. Of course this is not the case, and this is why.

')

Suppose we have a project in which 10 programmers, 3 testers and 1 project manager participate. Consider the time interval of one month (21 working days). The interval is chosen arbitrarily and is not really important.



Let the programmers write the code on the first working day and add 5 errors to it. The next day, testers found these 5 errors and wrote to the programmers. On the third day, the programmers fixed 5 errors. Here we have such a “troika” or cohort: one day we make mistakes, we find the second day, and the third day we correct.



Obviously, this cohort moves in time, and every day mistakes are added, detected and corrected. Although at each moment of time there are not too many active errors, the “window” is moving and the total amount of work done to identify and correct errors is quite significant. On the last day of the 21-day work cycle, the project manager got tired of it, he yelled at everyone and all the errors were corrected. As a result, at the end of the month, there were 0 errors in the draft. This, of course, will not last long, but the boss is happy with the beautiful total of the month.



Suppose, on this 21st day, one of the programmers downloaded the code analyzer, performed the check, received 0 case errors (and a couple of stupid triggers) and makes, at first glance, an obvious but incorrect conclusion: the code analyzers simply do not work and Not needed!



Now consider the movement of our cohort in case the code analyzer is used regularly.



On the first day, programmers also made 5 mistakes. But thanks to the automatic code analysis, 3 errors were immediately found and corrected at the coding stage. Therefore, the next day, testers will find only 2 errors. On the third day, programmers will have much less editing work, since some of the errors were corrected on the first day. It turns out that the analyzer has reduced the amount of work to eliminate errors by more than two times, which significantly speeds up the project development process as a whole.



Of course, the numbers above were given conditionally. The most important thing is that you can make the right important conclusion. Static analysis is most useful not as a one-time action, but as a regular process.