PVS-Studio: new trial mode

We sometimes experiment with the trial mode in order to make acquaintance with the PVS-Studio analyzer as efficient as possible. Now we again changed the format of the trial version. This note should answer all questions that may arise from developers who wish to get acquainted with our tool. In fact, this article is the answer to the question "Is it possible to try the demo version and what are the limitations in it?"

Story

Before describing the new trial mode, I want to remind you how it looked before and how it did not suit us. Then the reasons why we made some changes will be clear.

As it was before

The demo version did not functionally differ from the full version. The only limitation is the “number of clicks” (the previous demo mode is described in the 2012 article ).

A person could make a limited number of jumps to suspicious areas of code by clicking on the messages in the list:
')

Figure 1. The remaining number of "code transitions".

Every time a person “clicks” on the analyzer message, the counter is decremented by one. Of course, you can open the file manually and make the transition to the desired line. Then the "clicks" are not spent. However, I think everyone understands how slow and uncomfortable it is. Anyway, a static analyzer should save development time, and not increase. If a person is willing to spend time to navigate manually, we still will not sell him a tool.

In the beginning, the man was given 100 "transitions". Then he was offered a form where he could indicate and send information about himself. Then he was given another 100 "transitions."

There were very, very few emails with contact information, so we changed the proportion. Began to give at the beginning of 20 clicks, and another 200 can be obtained by sending us contact information. Unfortunately, this did not help. It became not very, very little, but just a little.

What we didn't like

The approach we chose had 2 problems. One small, related to the trial itself. And the second global one, connected with the complexity of demonstrating the capabilities of static analysis tools. Let's start with a smaller problem.

As it seems to us, a limited number of “clicks” discourages a person from becoming acquainted with the tool. Especially when there are only 20 of them at the beginning. A person starts to be greedy and just looks at the list, without going to specific parts of the code. In addition, some people think that only 20 transitions are provided at all, which spoils the mood.

However, this is all irrelevant compared to the next problem. We realized it by observing from the side how people install and begin to use our analyzer for the first time.

In a nutshell, programmers have too “playful hands”. They immediately go where they should not go and change the settings and modes of operation. It is clear that programmers are curious creatures, otherwise they would not be programmers. However, this can completely spoil the usage scenario that we propose to become familiar with our tool.

The most basic misfortune - people are starting to “turn on everything to the maximum.” This is the first thing they do. They include level 3 warnings and 64-bit diagnostics, which are turned off by default. So it seems to them that they have more control and they will be able to better assess the capabilities of the tool.

This does not mean that 3-level or 64-bit diagnostics are not needed. There are customers who use them and are grateful for them. But it is necessary to work with these diagnostics, selecting for yourself only the necessary.

If the programmer "included everything", then you can say goodbye to him, as with a potential user. He will be extremely disappointed with the tool. The reason - instead of useful messages, he sees meaningless noise. We watched it. People turn on everything to the maximum, and, after viewing 30 uninteresting messages, they lose interest. Everything. Positive dating did not take place.

Of course, it is not the programmer who is to blame, but the demo mode, in which the tool could not show itself from the best side. And with this it was necessary to do something.

By the way, we are not alone going through this topic. In the article " A Few Billion Lines of Code Later: Using the Static Analysis of the Bug in the Real World " there is the following thought:

Initial analysis reports are too high for people. If the first N messages contain false positives (N = 3?), They will begin to declare something like: “This tool sucks!”.

As you can see, if you include something extra - no chance. There is not something that the third message will be about a real mistake, God forbid the fiftieth. Once again, this does not mean that many diagnostics are useless. They are needed in certain projects, otherwise they would not exist. But not all.

What we decided to change

We decided to start hiding the click counter so that it would not embarrass people. Let the programmer quietly study the diagnostic messages, without looking at the decreasing numbers. The counter will appear after sending the information about yourself.

In the demo mode, we firmly disable the 2 and 3 levels of all diagnostics. And they can not be included.

Controversial decision. But we want to try this option. We need to show the programmer that there are errors in his code! To do this, we need to make it look at level 1 warnings, and it is not clear what.

It seems to us that the instrument has a much higher chance of appealing to people. And if you already liked the tool, then there will be no problem to accurately deal with the diagnostics and set up the analyzer. The most important thing is to find and immediately show errors in the code.

Total: new trial model

PVS-Studio can be downloaded here . The demo version has the following limitations:

1. Only 1 level messages are available for viewing.
2. You can perform 50 transitions by code. After this, the analyzer will offer the person to send information about himself. If he agrees, he will be given another 50 transitions.

The limitations of the demo version may seem harsh. However, we will benefit from such restrictions both we and you.

Viewing only the first level of warnings ensures that the person does not miss these mistakes. It is very important. It is necessary to immediately show the presence of errors in the code. This is useful for both us and the potential user.

A small number of “clicks” and a limitation of analysis by the first level will help to start communication in the mail faster. If someone wants to look at other messages, then we are ready to give him a registration key, say for 1 week. He just needs to write us a letter.

To receive letters and start communication is very important for us. Often we can help a person with some difficulties that arise when working with a code analyzer. We help to set something up, get rid of false positives, we explain the messages of the analyzer. Very often we can turn a negative impression into a positive one and make a person a client. It is enough to give him some magical setting. And to make this miracle, you need to communicate.

Try the demo version of PVS-Studio. And be sure to email us. We will help, prompt, issue a registration key for advanced study. Just do not be silent.

When communicating, we will make the PVS-Studio analyzer better, fix a lot of errors in your code and will stand guard over its quality! Email us: support@viva64.com

Additional links

1. Very good article for the first acquaintance with PVS-Studio. PVS-Studio for Visual C ++ .
2. Demonstration of analyzer capabilities. An updated list of articles in which we talk about errors found with PVS-Studio in open source projects.