To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
How we have solved an engineering task …

How we have solved an engineering task for several years in PVS-Studio

Aug 03 2011

At first I wanted to title this post "How PVS-Studio enables cheap integration of static code analysis into the development process" but I decided not to do it because of the ambiguous interpretation of the word "cheap". So I will tell you about one engineering problem we had to solve constantly to enable people to use our product. Going a bit ahead I want so say that we seem to have solved it.

0107-Engineering_task/image1.png

So, having developed the first full version of our static code analyzer (that was called Viva64 at the time and served to detect 64-bit errors) back in 2007, we faced an issue of tool's integration by our users. Our clients are companies that have at least several tens of developers and at least several hundred thousand code lines. Any static analyzer will generate plenty of warnings on a code of that size. For instance, our tool generated up to several thousand messages on one project.

Yes, of course, the trouble here is with false reports of analyzers. But any analyzer has false reports and you can't help it. A question rose what users were to do with a lot of messages they got? That is, the problem looked as follows: a potential user downloads a program (trial-version), launches it and gets ten thousand messages. It certainly makes him sad, he uninstalls the program - and one more client is lost for us.

The first thing we did is removing double messages at once. The analyzer checks C/C++ projects and sometimes it happens that an error in an .h-file is reported during the check of several .cpp-files that use it. We don't have this doubling. Then we added capabilities of analysis result filtering (and then we constantly improved them): filtering by error code, by message text, a capability not to check files by masks and so on. All this allowed us to significantly reduce the number of messages but only after customization. At the first use, a person would get a pile of messages all the same. So, message filtering is an important tool but it did not solve the initial problem - difficulty of integrating the tool into the development process.

Then the analyzer acquired the new mechanism "Mark as False Alarm". Its principle is adding comments of a special kind (//-V112) into the code to suppress the analyzer-generated messages. Having marked the code in such a way, in future you will get error-reports only for those code fragments that do not have this marking. Ideally it will be only newly added code. Although the problem of integrating the analyzer into the team development process became a bit simpler, still it required that several members of the team marked the code first to remove rubbish messages.

The next step towards solution of the integration problem was the capability to check only files modified during the last several days. It was much closer to the idea of starting to get profit from static analysis at once. But the problem remained. A user doesn't know about this feature and if we enable it by default it won't be clear why so few files are checked. But I repeat this again - the direction seemed right to us.

So we went on and made a new super feature "Incremental Analysis after Build". The analyzer now launches right after the compilation and checks only those files which have been affected by user editing. Unlike checking files for the last several days (when editing of the developer team was could be checked), the user now sees errors ONLY in the code he directly handles.

Programmers now won't worry about large sizes of code they do not deal with. Perhaps this code is older than 5 years; it virtually doesn't endure any modifications and most defects in it have been fixed. You don't need to rush and check this code first of all, and the analyzer doesn't. The programmer will see warnings only in the fresh code. And if he has some time left, he may check the project in full and peep into the most rarely visited places.

Yes, the analyzer still produces false reports. Yes, filters haven't become less important. But there is another thing that counts. We have managed to reduce the cost of INTEGRATION (costs of people's efforts on startup) of the static analyzer to zero. That is, a person now downloads the static analyzer, installs it and IMMEDIATELY starts getting profit from it without any additional efforts.

But there remained one last thing to complete the task. All was good, but it was difficult to notice it when the analyzer found errors. Color change of the PVS-Studio window's icon (as we made it in the beginning) is not so visible while in Visual Studio 2005 it doesn't work at all. The solution was to make a pop-up message.

0107-Engineering_task/image2.png

Surely, we all don't like all those importunate pop-up notes. But in this case it will be useful to programmers for sure and it will appear rarely on condition that they do not make a lot of errors in code.

So, the engineering task of integrating static analysis into the development process has been solved. That is why the Incremental Analysis after Build mode will be enabled by default in Incremental Analysis after Build.

The conclusion is simple. Now developers should not get afraid of difficulties of static code analysis integration because they can simply download PVS-Studio, install it and study errors that will be detected in newly developed code.

Popular related articles
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept