You decided to integrate PVS-Studio into your project. But suddenly it turns out that the manager is against it, because... because why, actually? Let's try to figure out what to do with potential objections.
The article is divided into sections on purpose: you don't have to read the whole text, but only the topic that concerns you.
Is this really a matter of price?
First of all, you need to understand, is it really about the price? Maybe some other concerns lurk behind it: the slowdown of the development process, integration difficulties, or something else? If so, then these very objections should be treated.
How can PVS-Studio be useful?
To justify the price, you need to understand how PVS-Studio can help in the development process.
The best option is to run the analyzer on the project code and see the issues it finds. You can download a trial version here.
I also recommend reading the following articles:
Tell your manager in which projects PVS-Studio has already detected bugs. Those include:
PVS-Studio still finds errors in their project code, although these projects are developed by professionals.
The full list of checked projects is available here. There you can also find links to articles describing the detected issues.
In fact, everything is exactly the opposite. To run the analyzer on a project, you need to:
This page will help you follow the steps above.
You can use a special filter to display the best warnings. If this filter is unavailable for your environment, I recommend you start viewing warnings from the 'High' level of certainty.
The documentation describes how to use the analyzer with different IDEs, CI/CD, as well as options for setting up the analyzer. For more information on introducing PVS-Studio into development processes, check the article "How to introduce a static code analyzer in a legacy project and not to discourage the team".
Any questions? Contact us. We will help you launch the analysis and deal with any possible difficulties.
Did PVS-Studio display a lot of warnings on first launch? It's all right, particularly for huge legacy code projects.
You need to:
While integrating the analyzer, perform baselining. This is what happens next:
And again, I recommend reading another article: "How to introduce a static code analyzer in a legacy project and not to discourage the team".
Note. If you are analyzing your code for security flaws, I suggest reviewing the most critical warnings (the "High" level) before suppressing all of them.
One of the stages of configuring the analyzer is to exclude third-party code that you don't plan to fix from the check, in particular:
The exclusion of this kind of code from analysis will not only decrease the number of warnings but also reduce the analysis time.
You can read about the way to exclude files and directories from analysis here.
The analyzer finds issues of different types, but not all of them could be relevant to your project.
Therefore:
In the documentation for specific IDEs and platforms, we explained how to disable diagnostic groups.
Sometimes static analyzers issue warnings for correct code. Such warnings are called false positives.
PVS-Studio has different mechanisms to deal with them. So, you can suppress false positive warnings either individually or by a template. The documentation describes exactly how to do this.
However, it can be useful to know what false positives are and why they can occur.
Look at this example:
Thread thread = new Thread(threadStartDeleagate);
thread.UnsafeStart();
An analyzer warning might look like this: V3082. The 'Thread' object 'thread' is created but is not started. It is possible that a call to 'Start' method is missing.
PVS-Studio was wrong and issued a false positive because it failed to understand the logic of the code.
If you faced a similar situation, contact us. We will enhance the analyzer to prevent issuing warnings on such code in the future.
There is another type of false positives. Let's inspect another example:
obj.SpecialMethod(obj);
anotherObj.AnotherMethod(anotherObj);
So, let's assume the analyzer displayed 2 warnings:
The SpecialMethod and AnotherMethod methods are specific to project. In the first case an object can be used as an argument to its own method, while in the second it can't.
So, in the second case the analyzer issued a correct warning, while in the first case it was wrong. If PVS-Studio is unaware of SpecialMethod and AnotherMethod, these calls will be equal for it. That's why in both cases the analyzer will issue a warning.
If this is an only case, then you can suppress a specific warning. If you see this kind of code regularly, it's better to suppress the warning by the template:
//-V:SpecialMethod:3062
After that, the analyzer will not be triggered on such calls.
The documentation describes the ways to suppress the warnings.
The analysis time depends on the machine resources and on the size and complexity of the code base.
If it seems like the analysis is taking too long, the analyzer freezes, or something else happens, please contact us, and we'll handle it.
If you just want to reduce the analysis time, try this:
We have already explained above the reasons for this and the ways to do it in the section "The analyzer displays a lot of warnings: but these warnings are irrelevant for the project's code".
Incremental analysis allows you to check only those files that have been modified since the last build. This is another way to analyze only new or modified code.
See the documentation for more information about this mode.
You can configure PVS-Studio to check individual commits / PR / MR, not the entire project. This will reduce the analysis time and allow you to find problems earlier.
For more details on this analysis mode, see the documentation.
Note. I still recommend regular analysis of the whole project together with the partial analysis. For example, during night tests.
When you use PVS-Studio with the distributed build system, you can perform analysis on multiple machines at once. This can greatly reduce the analysis time.
In this article, on the example of Unreal Tournament, we explained the change in the project analysis time with and without Incredibuild.
The documentation explains how to set up distributed analysis.
Note. Currently you can use PVS-Studio and Incredibuild to analyze only C and C++ projects.
Not really, you don't have to upload the code to third-party servers. PVS-Studio is the on-premises solution. You are free to choose where to perform the analysis:
If necessary, you can work with the analyzer fully offline.
The later you find the problem, the harder and more expensive it is to fix it. This is particularly true for security defects. The relative cost of fixing a problem at different stages of the software life cycle, according to the IBM System Science Institute, is as follows:
Defects found after the release are 15 times more expensive than those discovered at the development stage. Moreover, they are 100 times more expensive than defects discovered at the design stage.
Regular static analysis allows you to follow the shift-left principle, find problems earlier and thus vastly reduce development costs. Learn more on this topic here.
There may be several reasons for not detecting an error:
If you have any problems, just contact us and we'll handle it.
If you are considering trying the analyzer on a synthetic test, I suggest you read this article in advance: "Why I Dislike Synthetic Tests". And remember that often the real mistakes are simple enough. For example, typos in C++ (link) and C# (link) projects.
A static analyzer needs to be introduced into the development process in such a way that:
It is difficult to offer any practical advice on integration of the analyzer because a lot depends on the way the development processes in your team are organized. General recommendations may be as follows:
If the tool is beneficial for your project and is properly integrated into the development process, then there is no question about the purpose of its use.
This article will be updated and supplemented. If you can't find the answer to your question, please contact us! :)