# PVS\-Studio Output Window vs plain text stdout

В беседах с программистами, которые подумывают об использовании статического анализатора кода, часто можно слышать такое мнение: "Никакого особенного интерфейса для такого инструмента не надо, достаточно просто command line tool\. Да и вывод \(stdout\) всегда можно сохранить в файл"\. Я хочу показать ошибочность такого подхода на примере окна результатов PVS\-Studio Output Window\.

![0111-Output_window_vs_plain_text_stdout_ru/image2.png](https://import.viva64.com/docx/blog/0111-Output_window_vs_plain_text_stdout_ru/image2.png)

Итак, какую минимально\-необходимую информацию сообщает в своем отчете любой статический анализатор кода или компилятор, который выдает список сообщений об ошибках:

* код ошибки;
* текст сообщения;
* имя файла;
* номер строки\.

Действительно, на первый взгляд кажется, что эту информацию вполне можно представить в виде текстового файла или вывести на экран \(stdout\)\. И подавляющее большинство компиляторов так и делает\. А что же статические анализаторы? Может им тоже достаточно "выплюнуть все в stdout"? И как уловить отличие?

Отличие статических анализаторов от компиляторов в плане представления результатов своей работы заключается ровно в одном, но ключевом параметре\. Этот параметр – количество выводимых сообщений\.

Работая с компилятором, человек получает не так уж много сообщений от него\. Как правило, это несколько сообщений об ошибках \(не более десяти\), и может быть чуть больше \(несколько десятков максимум\) предупреждений\. При этом хорошим стилем является полное отсутствие предупреждений в проекте\. Естественно, бывают случаи, когда ошибок компиляции существенно больше, но они в общем количестве достаточно редки \(случае переноса кода на другую платформу либо глобальные изменения в используемых библиотеках\)\. Итак, еще раз, в обычном режиме работы пользователь получает от компилятора лишь несколько сообщений об ошибках\.

Работа со статическим анализатором идет в другом ключе\. Как правило, статический анализатор "натравливается" уже на существующий проект\. Причем, чем больше проект, тем больше желание команды использовать статический анализатор\. Что из этого следует? А то, что запуск на маленьком проекте даст сотни сообщений, на среднем – тысячи, а  на крупном \(годы командной разработки\) может быть даже десятки тысяч сообщений\. И со всеми этими сообщениями нужно как\-то работать, анализировать их и т\.п\. 

Так чем же отличается современное окно результатов статического анализатора кода \(на примере PVS\-Studio\) от plain text stdout? Перечислю сначала стандартные вещи, многие из которых есть в том же окне Error List в Visual Studio \(хотя для stdout и это не доступно\):

1. Навигация по коду\. Представьте себе, что вы берете и начинаете изучать новый инструмент\. Одно дело, если нужные строки кода вам придется искать в проекте руками или создать специальную утилиту, которая превратит лог в нечто, что может использовать среда разработки для навигации\. И совсем другое дело, если вы просто два раза кликнете мышкой по диагностическому сообщению\. Согласитесь, что в первом варианте изучение инструмента может закончиться, даже толком не начавшись\.
1. Сортировка\. На первый взгляд не обязательная операция\. Но если вы захотите работать с большим проектом, то она вам обязательно понадобится\. 
1. Быстрый и удобный доступ к справке по коду ошибки\.

Теперь возможности окна, важные именно для статического анализатора\.

1. Возможность пометить некоторые сообщения как ложные срабатывания \("[Mark As False Alarm](https://pvs-studio.ru/ru/docs/manual/0017/)"\)\. Например, в PVS\-Studio это сделано через добавление в код специального комментария вида "//\-V124"\. Но размещать такой код вручную неудобно \(хотя никто не мешает\), поэтому проще кликнуть в окне "Mark As False Alarm"\. Простой текстовый вывод не позволит удобно использовать этот механизм\.
1. Возможность на лету фильтровать сообщения\. Можно скрыть или показать сообщения с определенным кодом ошибки, содержащие какие\-то конкретные слова и т\.п\. Это очень удобно, так как сообщений много и перезапуск анализатора – длительная задача\. Конечно, тут можно попробовать возразить, что есть чудесные unix\-утилиты вроде grep, sed, awk и так далее, но это, мягко говоря, на любителя\.

Даже когда статический анализ будет внедрен на проекте и не будет уже выдавать большого количества сообщений, все равно работать с ними намного удобнее через такое специализированное окно\.

Пять перечисленных возможностей окна вывода сообщений наглядно показывают, что работать со статическим анализатором намного удобнее, когда у него есть подобный интерфейс\. И говорить "достаточно лишь вывода в stdout" можно только от непонимания\. Этого достаточно теоретически\. Но на практике использовать инструмент будет невозможно, пока Вы сами для себя не создадите аналогичную инфраструктуру \(возможность переходить в код, сортировать, фильтровать и так далее\)\.