New service: regular C / C ++ code audit

Until recently, we were engaged exclusively in the development and sale of the PVS-Studio product. Then we thought and decided to offer a new service: regular code auditing. I will tell you about it. The article is intended for managers and timlidov. In order not to spoil my mood and not minus, programmers ask you not to read the article.

The troubles of static analysis as a product

Static analysis tools have several drawbacks, causing psychological discomfort and real drawbacks. Many managers understand everything perfectly and are ready to put up with inconveniences, since static analysis is generally beneficial. Unfortunately, the introduction of static analysis tools can be met negatively by programmers. Since in some cases it is difficult to sell and implement regular use of static analysis, we decided to try to sell not a tool, but a service.

Let us analyze at the beginning of the reason, because of which the static analysis tool can be negatively perceived by developers.

1. Trying a static analysis tool, the programmer sees few real errors and many false positives ( explanations ). Go into the details of the methodology of static analysis, the developer does not have time and do not want. He has a lot of current affairs. Therefore, he seeks to quickly decide that the tool is useless and return to previous cases. Fortunately, this is not so scary. The programmer can be explained that the main advantage of static analysis in regular use, and not in one-time checks. A good analogy is the compiler warnings. After all, he does not include them a couple of times a year, but works with them constantly.
2. Nevertheless, even during trial runs, PVS-Studio manages to find real errors in the code. Because of this, unfortunately, it can turn into a natural enemy. Some do not know how to tolerate criticism. Even if it is the output of the program. Such a conclusion can be made both by logical conclusions and by negative, which sometimes falls on us. From the outside it is difficult to understand. If the code contains errors, it is good for the company. But for a person who made a mistake, this is unpleasant. He will not give a look, but will unconsciously try to avoid a situation where someone else finds an error, and not himself. This can be achieved by making sure that static analysis is no longer used. Irrational decision in terms of teamwork, but the person feels more comfortable. It is because of this sabotage that some heads of development departments take on the role of analyzing diagnostic warnings. In such a situation, the programmer has nowhere to go. Programmers after reading this item will be outraged. That is why I did not recommend this text to them for reading :).
3. It seems that static analysis takes time away from work. The time that a person will regularly spend on setting up the analyzer and regularly working with it is noticeable. But it is completely incomprehensible how much time and effort the quickly eliminated typo saved by analyzing the code will save.
4. Let's move from psychological discomfort to practical inconveniences. Often, programmers do not understand what the static code analyzer wants to tell them. Unfortunately, PVS-Studio does not have artificial intelligence to compose a story about why there might be a mistake here. This is a big real problem. Programmers are not to blame. It takes time and experience to learn to understand the messages of the analyzer. As a result, the capabilities of PVS-Studio remain undervalued. I see it well from communication in support. People write that they have encountered this or that false trigger and offer to correct it. In the process of clarification, it often turns out that this is a real mistake, and the developers did not notice it or could not even assume that such a situation might be. It is sad. After all, we are talking about those who wrote to us. You can make the assumption that many of these errors are not perceived and marked as a false positive. By the way, such a disaster is not only with static analyzers. Even the compiler behavior is interpreted incorrectly ( examples ).
5. False alarms. Unfortunately, they were, are and will be. This is the essence of the static code analysis methodology. False positives can be fought by improving the code, or suppressing them with the help of settings. In any case, this is work and they are not interested in working. Plus, this again takes time to gain experience. False alarms spoil the impression of the product. But, selling PVS-Studio as a product, we cannot do anything about it.

As you can see, there are several objective and subjective reasons that interfere with how to evaluate static analysis and regularly use it.

We decided to propose a workaround for managers that will allow us to start using the static code analysis methodology in our work as quickly and efficiently as possible.
')

New offer: audit

I will describe how the audit process is built and its benefits.

Process:

1. We sign the NDA, which will allow us to pass the code.
2. We conclude a contract. We focus on annual contracts. However, you always want to try at the beginning. Therefore, it is possible to conclude a trial three-month contract. Less than 3 months to conclude a contract is meaningless. We need to learn how to compile your project, learn how to automatically download updates, learn how to check it, configure the analyzer, make your admins not to ban our letters, and so on. Until all these questions are settled, a month will pass. And you need at least 2 months to evaluate the benefits of cooperation.
3. At the first stage, our employee will review all general-purpose diagnostic messages issued by the analyzer and provide a report on the defects found. After that, the daily audit of the new code will begin.
4. A dedicated, experienced employee deals daily with your project. If something breaks, it repairs the project build. And most importantly, viewing the results of the analysis. If he finds a suspicious place in the code, he will notify you. At the same time, he can notify the nominal employee who laid the code leading to the warning.
5. In case the error is not obvious, our employee explains it, and also provides advice on how to fix it better.

Audit benefits:

• You do not need to think whether there is a Linux version of PVS-Studio or not. It is our task to adapt the analyzer for your operating system and compiler. If you have not used to develop something exotic, we will be able to verify your code.
• Employees cannot consciously or unconsciously sabotage regular code checking. They will have nowhere to go.
• We get money for looking for mistakes. So they are interested to be attentive to the warnings of the analyzer. The programmer is inclined to call an error not an error, or simply lazy to change the obviously bad code. In the case of an audit, everything will be visible. We get the advantage: the mistakes that PVS-Studio has found are not ignored, which confirms the value of the tool. You get the advantage: a careful analysis of diagnostic messages.
• Your programmers do not work with false messages. You do not need to make any changes to the code to eliminate the false positives. You get information only about real problems in the code or obviously bad code. False alarms are our problem that we can handle. A programmer’s dream comes true - you get a tool that will almost never give false positives!
• Information about the defects found comes to the manager and specifically to the programmer who wrote the dangerous code. A programmer can easily fix his own code. The manager will see the big picture.
• We well understand how the static analyzer works. Therefore, we will be able to supply the diagnostic messages of the analyzer with additional comments that will help a person understand the reason for the warning. This is a very important point. This error will not be inadvertently marked as a false positive.
• If desired, the auditor may make general recommendations for improving the code. It will also help improve the coding standard used in the company.

Lack of audit:

• More delayed reaction to a defect in the code. The most effective mode is to check the code immediately after compilation. PVS-Studio has an automatic analysis mode for this. In the case of an audit, you will receive a report once a day. This, of course, is also very good, but still, belatedly.

Prices

We estimate 1 month of audit at 100 000 rub. It is economical. Let's count.

To do the audit of the code yourself, first, you need to purchase a PVS-Studio license. Secondly, there should be a highly paid specialist in the staff who will regularly engage in project analysis, study the analyzer reports, report bugs to programmers and help them with advice. For simplicity, let us leave aside that such a specialist should still go search. Another problem.

Taking into account the purchase of a license, the salary of a new qualified employee, as well as that the employee requires additional overhead costs (salary tax, office space, a powerful computer for running tests), then you can’t meet 100,000 per month.

Thus, a remote audit can cost your company not only cheaper, but it will be much easier to implement it. They will do everything for you. You only need to provide access to the sources and analyze information about errors found in the code.

Contacts

If you are interested in a regular audit of the code, then you can contact us using the feedback page or via e-mail: support@viva64.com .