Sometimes our potential clients ask about examples of successful integration of PVS-Studio in various companies. Their interest is understandable. After Case Study by Microsoft in the form "the Formual-1 McLaren team has begun to use the new SQL Server and their results has become so much better that..." you really want to see benefit from a particular tool.
But for small companies (us being such a company) it is difficult to make such materials due to organizational and juridical issues.
First, the point is in the way a product is being sold. We are selling our solution through the Internet and it is not always the end user who makes the purchase. For instance, some large company (like Intel) buys a license through some reseller (for instance, SHI). All that happens without our people participating. And although we see that some company has bought the product for some client, the client's contact information is most likely information of the procurement department. So, sometimes we cannot even communicate with the end user.
Second, the juridical aspect often does not permit the client company's employee to disclose such information as, for example, organization of the development infrastructure: how many and what build systems are used, what management systems are used, how many developers participate in the process and so on. While Microsoft can push coordination of all these data through the McLaren management, small organization hardly can do that.
Because of this, it is almost impossible to give information about instances of successful integration and especially errors found with the help of the analyzer.
But we see another way to show that we are actively participating in integrating PVS-Studio into the development process and do not leave our clients alone with our tool. We can tell you about modifications we do for them by their requests.
First of all, we always improve the analyzer if it does not process some code fragments completely. Incomplete support of the language might seem a drawback of the analyzer - but no analyzer can actually boast about support for all the types of templates or C++0x syntax; even compilers might have errors. We always quickly and efficiently solve issues related to incomplete parse of code.
Some clients might need diagnostic of specific errors. Sometimes they offer new diagnostic rules themselves, sometimes they only show us errors and we formulate the rules. Anyway, implementation of diagnostic rules for a particular client is a very important part of our support.
Convenient integration of code analyzers into the development process is a guarantee of its satisfactory use. We have implemented the following features by requests of our clients:
In conclusion we should say that we always and quickly help users to solve any issues since we are a small company for now :-).
Many programmers think that the more error messages a static code analyzer produces, the better. It would be true if all the messages hit the bull's eye, as they say. But this is impossible: the same warnings may be considered both true and false by different programmers depending on the project type. There is also one more important and interesting ...