Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

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

close form
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

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

close form
check circle
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.

>
>
PVS-Studio Output Window vs plain text …

PVS-Studio Output Window vs plain text stdout

Oct 12 2011

While communicating with programmers who ponder over the idea of using a static code analyzer, you may often here them say: "You don't need any special interface for a tool of that kind. A simple command line tool will do. And you can always save stdout into a file". I want to show you what is wrong about this way of thinking by the example of PVS-Studio's Output Window.

0111-Output_window_vs_plain_text_stdout/image1.png

So, this is the minimum information you can see in a report file of any static code analyzer or compiler that generates a list of error messages:

  • error code;
  • message text;
  • file name;
  • line number.

Really, it seems that you can well arrange this information in a form of a text file or stdout. Most compilers actually do it that way. And what about static analyzers? Maybe they can "spit it all into stdout" too? And how do you tell the difference?

The difference between static analyzers and compilers regarding results representation is only one yet crucial parameter. This is the number of messages output.

When you deal with a compiler, you don't get too many messages from it. Usually there are several error messages (not more than ten of them) and a bit more (about several dozens at most) warnings. Complete absence of warnings in a project is considered a good style. Of course there are cases when there are much more compilation errors but they are rare compared to the total number (when porting the code to a different platform or when libraries being used undergo global changes). So, once again, a user gets just a few error messages in the usual operation mode.

Handling a static analyzer is quite a different thing. Usually a static analyzer is "being set on" an already existing project. And the larger the project is, the greater urge the team feels to use a static analyzer. What follows from that? A static analyzer will generate hundreds of messages for a small project, thousands of messages for a medium project, and a large project (the team has been working for years on) will cause even dozens of thousands of messages. You have to handle all these messages somehow, analyze them and so on.

So what is the difference between the contemporary output window of a static analyzer (for example, in PVS-Studio) and plain text stdout? I will first enumerate common things many of which can be found in the Error List window in Visual Studio (although stdout cannot do even that):

  • Code navigation. Imagine you sit down and start studying a new tool. It's one thing when you have to search for code lines in the project manually or create a special utility to turn the log into something that could be used by the development environment for navigation purposes. And it's quite a different thing when you just click twice on a diagnostic message. You agree that studying of a new tool in the first case might end without really having started, don't you?
  • Sorting. At first sight this operation is not so much necessary. But if you want to handle a large project, you will really need it.
  • Quick and convenient access to the help system by the error code.

And now let's see what capabilities significant especially for a static analyzer are provided by a window.

  • You can mark some messages as false reports ("Mark As False Alarm"). For instance, in PVS-Studio this feature is implemented through adding a special comment of the "//-V124" kind into the code. But it's not convenient to add this code manually (although nothing prevents you from doing this), that's why you may simply click the "Mark As False Alarm" command in the window. Simple stdout won't let you use this mechanism with that convenience.
  • You may filter messages on the fly. You may hide or display messages with a certain error code or messages containing certain words and so on. It is very convenient since there are a lot of messages and relaunching the analyzer is a long process. Of course, you may argue that there are wonderful unix-utilities like grep, sed, awk and so on, but they are, to put it mildly, for true fans.

Even when static analysis gets integrated into a project and the number of messages generated is few, it's still much more convenient to handle them through a specialized window.

The five advantages of message output window I have listed show it very well that it's much more convenient to handle a static analyzer when it has such an interface. Phrases like "stdout is enough" result from lack of understanding. It's "enough" only in theory. But in practice it will be impossible to use a tool until you create a similar infrastructure for yourself (the capability to navigate on the code, sort and filter messages, etc.).

Popular related articles


Comments (0)

Next comments next comments
close comment form