As in PVS-Studio, we solved one engineering problem for several years.

At first, I wanted to call this note “How PVS-Studio allows CHEAP to introduce static code analysis into the development process”, but did not dare because of the ambiguous interpretation of the word “cheap”. Therefore, I will talk about one engineering problem that we constantly had to solve in order for people to use our product. Looking ahead, I will say that I think we have solved it.



So, having developed the first version of the static code analyzer (which was then called Viva64 and detected 64-bit errors) at the beginning of 2007, we were faced with the problem of introducing the tool with clients. Our client is a company in which at least several dozen developers, and at least several hundred thousand lines of code. Any static analyzer on such a code will give a bunch of warnings. For example, we received up to several thousand messages per project with our tool.
')
Yes, of course, there is a problem with the false positives of the analyzer. However, any analyzer has false positives and cannot get away from them. There was a question - what to do with a large number of messages that the user receives? That is, the problem looks like this. The potential user downloads the program (trial), starts it and receives ten thousand messages. Naturally, it saddens him, then uninstall, and we lost the client.

The first thing we did was immediately remove the duplicate messages. The analyzer checks projects in C / C ++ and it happens that an error in the .h file can be generated when checking several .cpp files that use it. We do not duplicate it. Then we added the ability to filter the analysis results (and constantly improve them): filtering by error code, by message text, the ability to not check files by mask, etc. All this allowed to significantly reduce the number of messages, but only after setting. The user for the first time still received a mountain of messages. Thus, message filtering is an important tool, but it did not solve the original problem — the difficulty of integrating the tool into the development process.

Then a new mechanism “Mark as False Alarm” appeared in the analyzer. This is an insertion into the code of comments of a special type (// - V112) for suppressing the messages of the analyzer. By marking the code in this way in the future you can receive messages about problems only in those code fragments where there is no such markup yet. Ideally, this is just a new code. Although the problem of integrating the analyzer into the team development process has become a bit simpler, all the same, it is necessary that several people from the team first tag the code, eliminating the obviously garbage messages.

The next step to solving the implementation problem was the ability to check only files modified in the last few days. This is much closer to starting to benefit from static analysis right away. But the problem still remains. The user does not know about this feature, and if it is turned on by default, it will not be clear why so few files are checked. But, again, the direction seemed to us correct.

Therefore, we went ahead and made a new super feature “Incremental Analysis after Build”. Now the analyzer is launched immediately after compilation and checks only those files that were “hit” by the user's edits. Unlike checking files for several days (when edits of the development team could be checked), now the user sees ONLY errors in the code that he directly touches.

The programmer will no longer worry about a large amount of code that he does not touch. Perhaps this code for more than 5 years. It is practically not modified and most of the defects in it have already been fixed. This code does not need to rush to check in the first place and the analyzer does not. The programmer will see warnings only in fresh code. And if he has extra time, he will always be able to check the whole project, looking in the most rarely visited places.

Yes, there are still false analyzer alarms. Yes, all the same, filters have not lost their relevance. But another important. We managed to reduce the cost of IMPLEMENTATION (the cost of human effort for commissioning) of the static analyzer to zero. That is, now the person downloads a static analyzer, installs it, and immediately starts to benefit from it without any additional actions.

However, it lacked the finishing touch. Everything is good, but only that the analyzer found errors was very poorly noticeable. Changing the color of the window icon of PVS-Studio (as we did at first) is not so noticeable, and in Visual Studio 2005 it will not work at all. The solution was a pop-up notification.

Of course, we all do not like all sorts of annoying pop-up notifications. But in this case, it will be clearly useful to the programmer, and will rarely appear, provided that he does not abuse errors in the code.

Thus, the engineering problem of introducing static analysis into the development process was solved. Therefore, in PVS-Studio 4.34, the Incremental Analysis after Build mode will be enabled by default.

The conclusion is simple. Now, developers can not be afraid of the difficulties of implementing static code analysis, but simply download PVS-Studio, install it and look at the errors that will be detected in the newly developed code.