Решил собрать в одном месте отзывы различных людей, касающиеся нашего статического анализатора кода PVS-Studio. Некоторые отзывы приведены целиком, другие частично. С оригинальными отзывами можно познакомиться, перейдя по соответствующим ссылкам.

Пора слов о PVS-Studio, если вы ещё не знаете что это такое

PVS-Studio — это инструмент для программистов, использующих языки программирования Си/Си++/Си++11. Инструмент представляет собой статический анализатор кода, выявляющий ошибки и другие недостатки в исходных текстах программ. Анализатор ориентирован на разработчиков Windows приложений. На данный момент PVS-Studio интегрируется в среду Visual Studio 2005/2008/2010, а также скоро будет поддерживать VS 2012. Возможна проверка проектов, собираемых с помощью MinGW. Подробнее с анализатором можно познакомиться по ссылке: http://www.viva64.com/ru/pvs-studio/ ^[1]

Теперь предлагаем изучить некоторые из накопившихся у нас отзывов.

О проверке нами Open-Source проектов

Автор: Джон Кармак ^[2].

Источник: запись ^[3] в твиттере (EN).

Здорово, когда инструменты статического анализа кода используют набор приложений с открытым кодом для демонстрации своих возможностей: http://www.viva64.com/en/a/0079/ ^[4]

Джон Кармак об опыте использования PVS-Studio

Автор: Джон Кармак ^[2].

Источник: цитата из статьи "Статический анализ кода ^[5]" (EN).

Следующим инструментом, который я изучил, был PVS-Studio ^[6]. Он легко интегрируется в Visual Studio и имеет удобный демо-режим (обязательно попробуйте!). Если сравнивать его с /analyze, PVS-Studio мучительно медленный, но все же он выявил несколько дополнительных критичных ошибок даже в том коде, который уже был полностью вычищен с точки зрения /analyze. Помимо выявления дефектов, которые являются ошибками с логической точки зрения, инструмент также способен находить ряд проблем, относящихся к общим программистским ошибкам, даже если код написан вполне адекватно. Почти гарантировано, что вы получите несколько ложных предупреждений, но, черт побери, ведь даже подобные недочеты общего характера иногда необходимо исправлять.

На сайте ^[7] PVS-Studio собран ряд хороших статей, большинство из них содержат примеры из проверенных открытых проектов, демонстрирующие конкретные типы ошибок, которые инструмент умеет находить. Я подумывал над тем, чтобы добавить несколько показательных предупреждений, выдаваемых статическими анализаторами, к этой статье, но оказалось, что в материалах по PVS-Studio можно найти еще более детально описанные примеры. Так что советую взглянуть на них, и не надо самодовольно улыбаться и думать: «Я бы так никогда не написал!»

PVS-Studio умеет находить в программах много интересного

Автор: MetaQuotes ^[8]

Источник: комментарий ^[9] к статье (RU).

Это очень хороший анализатор, работающий совершенно с новым режимом поиска ошибок.

Например, вы много лет методично чистите свои проекты с помощью Lint + Visual Lint + свои тулзы, а потом запускаете PVS-Studio.

Думаете, что уже и так все вычищено. Но в результате видите в своих проектах (миллионы строк С++ кода) глупейшие ошибки копи-паста, одинаковые ветви условий и еще ряд механических ошибок. Пару суток работы и проект избавляется от очередной толпы ошибок.

Лично мы не нарадуемся PVS-Studio — это отличное дополнение к Lint и Intel Parallel Studio (все лицензионное).

Надо поддерживать такие компании — отзыв от чистого сердца.

Фоновый инкрементальный анализ — это замечательно

Автор: Сергей Власов ^[10]

Источник: цитата из статьи "Обзор статического анализатора кода PVS-Studio для Visual Studio ^[11]" (EN).

В целом, PVS-Studio показал, что он умеет находить нетривиальные ошибки с довольно небольшим количеством ложных срабатываний (например, Visual Studio выдавал мне более 200 предупреждений). Процедура анализа очень медленная, но наличие фонового инкрементального анализа, позволяющего проверять только модифицированные файлы после каждой сборки, отчасти компенсирует этот недостаток. Интеграция с Visual Studio проходит очень легко и весьма удобна.

Сравнение PVS-Studio с PC-Lint и Klocwork

Автор: Александр Лотохов ^[12]

Источник: цитаты из статьи "Еще одно тестирование PVS-Studio ^[13]" (RU).

PVS-Studio, похоже, ориентирован исключительно на работу с Visual Studio. После инсталляции он автоматически интегрируется в установленную версию студии. На этом все необходимые шаги по интеграции заканчиваются. Осталось запустить саму студию — и в ней уже будет новый пункт меню PVS-Studio. Столь прозрачная интеграция — выше всяких похвал!

...

Вывод результатов анализа — в отдельной вкладке PVS-Studio. Сделано все весьма удобно: по каждой найденной (потенциальной) проблеме показывается описание, место (файл и строка), а также ссылка на подробное описание проблем данного типа: почему это проблема, каким образом ее можно исправить и т.п. Описания сделаны очень подробно и качественно!

...

И напоследок — краткое сравнение PVS-Studio с PC-Lint и Klocwork.

PVS-Studio гораздо более удобен в использовании, чем PC-Lint. Основная проблема PC-Lint — слишком большое количество потенциальных проблем, на этом же проекте с установками по умолчанию он выдает более 23 тысячи сообщений! (PVS-Studio — лишь 42). При этом PC-Lint не умеет скрывать повторяющиеся проблемы (если один и тот же .h файл подключается из двух .c файлов, то PC-Lint покажет проблему в .h файле дважды, а PVS-Studio — только один раз). И в PC-Lint нельзя отметить как false positive отдельно взятую проблему, можно только «выключить» весь класс проблем.

При этом если хорошо покопаться в горе «мусора», выдаваемой PC-Lint, то там можно найти больше реальных потенциальных проблем, чем находит PVS-Studio (который, например, не нашел отсутствие виртуальных деструкторов в паре классов, равно как и отсутствие явно определенных конструкторов копирования и конструкторов по умолчанию). Другое дело, что в PC-Lint эти полезные крупицы обычно «тонут» среди остальных, не столь критических сообщений.

При этом PC-Lint более универсален, хотя и гораздо более сложен в использовании, хотя интеграция в Visual Studio у него тоже достаточно простая.

Но в целом здесь PVS-Studio — безусловный лидер. Ибо с ней можно просто взять и начать работать, чего не скажешь о PC-Lint, где только на просмотр всех выданных сообщений легко может уйти пару дней!

А вот по сравнению с Klocwork PVS-Studio, увы, проигрывает. Прежде всего по удобству использования (отмечу только отслеживание состояния от билда к билду — сколько проблем было исправлено, сколько осталось, а сколько добавилось, а также удобные отчеты), универсальности и лучшему нахождению критических потенциальных проблем. К тому же Klocwork — серверная многопользовательская система, с возможностью назначать ответственных за каждую найденную проблему и работать сразу с несколькими проектами, легко отслеживая статус каждого.

Если сравнить по ценам, то получится вот такой расклад (информация с сайтов разработчиков):

• за PVS-Studio просят €3500 евро за 5 лицензий или €9000 за 30, за год использования.
• за PC-Lint — $389 за одну лицензию или $3500 — за 10, неограниченно по времени.
• за Klocwork — €30000 за пакет «сервер + 20 клиентов» за год использования.

Что же, цена примерно соответствует функциональности, PVS-Studio где-то посредине между дешевым, но тяжелым и неудобным в использовании PC-Lint и удобным и красивым, но дорогим Klocwork.

У нас интересные материалы на сайте

Автор: justinvh

Источник: комментарий ^[14] на сайте reddit.com (EN).

Честно говоря, я был поражен, насколько интересным оказался инструмент PVS-Studio. К тому же, сопровождающие материалы написаны четко и понятно. Инструмент стоит того, чтобы хотя бы немного ознакомиться с ним и получить представление о его возможностях. Обычно я пользовался статическим анализатором clang, чтобы разобраться с небольшими ошибками, но PVS-Studio определенно показал себя достойно в сфере 64 бит.

Вдобавок, было забавно почитать сборник 64-битных уроков ^[15].

Я использую его при портировании Doom3 и он действительно очень крут. Разработчики оказывают хорошую поддержку студентам, так что если вы хотите провести лекцию в вузе на тему сравнения статических анализаторов (как было в моем случае) или просто хотите узнать побольше об их продукте, напишите им по e-mail и спросите, все что нужно.

Время от времени возникали некоторые странности, но, по меньшей мере, было очень интересно посмотреть на инструмент в действии; жалко, что мне приходилось каждый раз запускать его на виртуальной машине, но то, что он легко интегрируется с Visual Studio — очень классно. На данный момент я использую clang в качестве препроцессора, и все вместе также работает очень быстро.

Как сказал Кармак ^[16], вы точно найдете баги.

С помощью PVS-Studio легко освоить методику статического анализа кода

Автор: Anteru

Источник: цитата из статьи "Обзор: PVS Studio ^[17]" (EN).

Если вы новичок в сфере статического анализа, рекомендую вам попробовать PVS-Studio (у них есть пробная версия ^[18]). Статический анализ C++ кода все еще находится на ранней стадии развития, но уже сейчас инструмент наподобие PVS-Studio может помочь вам найти скрытые ошибки. Особенно если ваша база исходных кодов еще не была проверена юнит-тестами, статический анализатор быстро подскажет вам, какие фрагменты кодов в вашей базе стоит просмотреть.

И да, пока не забыл: инструмент регулярно обновляется, и поддержка работает хорошо — так, я доложил об ошибке в самом начале написания обзора, и она была поправлена за пару дней.

Еще раз спасибо команде Viva64 за то, что предоставили мне копию анализатора для рецензии, продолжайте так же хорошо делать свою работу!

PVS-Studio полезен при освоении 64-битных платформ

Автор: Алекс Чачанашвили

Источник: цитата из статьи "Проверка кода с помощью PVS-Studio ^[19]" (EN).

Инструмент в целом мне понравился — он действительно нашел несколько некритичных проблем в серверном коде, но если честно, большую часть своего кода я прогонял через FlexeLint и BoundChecker (до тех пор, пока не истекла лицензия). Я также запускал Visual Studio на 4 уровне предупреждений для проверки отладочных сборок, и он находит много дефектов.

Основная заслуга PVS-Studio ^[20] в том, что он хорошо отлавливает дефекты, влияющие на перенос 32-битного кода на 64-битные платформы.

Мы молодцы

Автор: Фернандо Морейра ^[21]

Источник: комментарий к презентации ^[22] (EN).

Ага, я действительно попробовал его и сразу же стал поклонником :) Теперь я рекомендую его каждому разработчику у нас в лаборатории. Инструмент безболезненно интегрируется с VS и он действительно способен научить разработчиков важным вещам, привлекая внимание к определенным типам неизвестных проблем/ловушек.

До сих пор не получил ни одного ложного предупреждения, и это здорово!

Вы, ребята, делаете серьезное дело!

О рекламе PVS-Studio и Coverity

Автор: nomarketingbs

Источник: вставлю статью "How to Not Present Static Analysis Results ^[23]" (EN) целиком, так как не знаю, что в ней выделить.

Помимо того печального факта, что Coverity нельзя попробовать, не получив предварительно Печать Одобрения Сотрудников Отдела Продаж Coverity, существует еще одно значительное различие между Coverity и PVS-Studio, которое любой может заметить. Это...

КОММЕРЧЕСКИЕ МАТЕРИАЛЫ

Как можно делать

Давайте взглянем на типичный скан-отчет PVS-Studio. Вот этот ^[24] как раз попался мне под руку, так что я и дам на него ссылку.

Опечатка… Ага, вижу. Возможность выхода за пределы массива… Вижу. Несколько более мелких недочетов… Вижу. Не имею ни малейшего понятия, как эти недочеты могут повлиять на работу программы, но представлены они исключительно ясно, и вы можете легко оценить их значимость, если сочтете нужным обратить на них внимание.

Кто-нибудь может задуматься, как же программа могла работать, имея в коде все эти ужасные ошибки.

Все очень просто. Проблемы, которые явно вылезают в тексте программы, были обнаружены ранее с помощью других методов — старой доброй отладкой, юнит-тестами, экспертной оценкой, чем-то еще. А вот чтобы обнаружить все остальные дефекты, нужно приложить некоторые усилия. Это может быть, например, необычный набор данных. Или нетипичный алгоритм действий пользователя. Или необычная индикация ошибок. А может быть, обновление версии компилятора или библиотеки C++.

Ошибки есть ошибки. Как говорят, нельзя солгать компилятору, но не все ошибки равноправны. Те самые мелкие недочеты могут прятаться в вашей базе много лет, а затем кто-нибудь прогонит ее через PVS-Studio, и… «УХ ТЫ, СКОЛЬКО ЖЕ ТУТ СТРАШНЫХ БАГОВ, БОЖЕ МОЙ1111!!!» — воскликнет он.

Так что скан-отчет мало что дает сам по себе — все равно он требует от разработчика, который знаком с базой кодов, чтобы тот оценил и по возможности решил каждую указанную проблему. Скан-отчеты в PVS-Studio делают именно то, что должны — они показывают найденные ошибки одну за другой, давая краткие пояснения — ничего лишнего.

Как не надо делать

Теперь давайте посмотрим на коммерческие материалы Coverity. Вы едва ли отыщете скан-отчет с результатами анализа Coverity вроде того, на который я ссылался выше. В то же время ребята из Coverity иногда выпускают Отчеты о проверке целостности открытых продуктов (Integrity Report).

Integrity Report — это восторженный документ, содержащий такие слова как «миссия», «бесшовная» и «концентрируемся на инновациях». Неплохо для затравки — по крайней мере, наличие таких ключевых слов однозначно показывает, что на первых трех страницах хватает маркетинга.

Переходим к Таблице A… О, эта табличка показывает распределение размеров проектов. Каким-то образом, использование слова «распределение» подразумевает, что собранные данные имеют некую статистическую значимость, а потому заслуживают особого доверия. Что ж, если у вас 45 проектов, и вы пытаетесь построить график на их основе, то называть это «распределением» очень глупо. Видите ли, у них ДВА проекта, в которых более 7 миллионов строк кода. Невероятно, слов нет.

Весь остальной текст Отчета также наполнен подобными абсолютно бессмысленными табличками. Да, круто, что вы нашли 9,7654 ошибок на квадратный фут какого-нибудь проекта. Но до тех пор, пока вы не дадите мне попробовать вашу программу, мне все равно, эти цифры для меня значат не больше, чем заявление о достижении эффективности в 132 процента (посту уже пять лет, но он до сих пор актуален ^[25]).

Перемотаем вперед до приложения A. Таблицы 2 и 3 обобщают ошибки, но при этом распределяют их по категориям и указывают степень их воздействия на работу программы. Давайте посмотрим...

Ошибки потока управления. Что это? Это когда я забываю написать «break;» в конце «case» в высказывании «switch», что ли? Вы говорите, оно оказывает среднее воздействие… Ладно. Как насчет «main()», возвращаемого сразу же? Это также ошибка потока управления, и не говорите мне, что она оказывает среднее воздействие. Не все ошибки потока управления равноправны.

Разыменовывания нулевых указателей также оказывают среднее воздействие, верно? Ага, мой код тут и там разыменовывает нулевые указатели, и каждый раз пользователи получают конфетку. Может быть, авторы Отчета имели в виду потенциальные разыменовывания нулевых указателей, когда код разыменовывает указатель, не проверив перед этим, что он не является нулевым. Хорошая новость в том, что если проверять указатель на нулевое значение каждый раз, когда мы собираемся его разыменовывать, то это будет сильно загромождать код. Опять-таки, не все ошибки разыменовывания нулевых указателей равноправны.

Дефекты обработки ошибок. Что это? Имеется в виду проверка кодов ошибок Win32 API функций? Конечно, каждый раз, когда программа пытается открыть файл, не оценив успешность этой попытки, и продолжает чтение дальше — это ничего страшного, скажет пользователь. Нет доступа к папке? Ну ладно, сделаем вид, что файл сохранен. Не все дефекты обработки ошибок равноправны.

Проблемы работы с целочисленными типами оказывают среднее воздействие. Точно, переполнение целочисленного типа при вычислении размера выделяемой памяти — ерунда какая. Просто выделяйте, сколько получится, и будем считать, что это нужное количество. Не все проблемы работы с целочисленными типами равноправны.

Работа с незащищенными данными оказывает среднее воздействие. О чем вы? Без понятия, но что-то подсказывает мне, что не все ситуации работы с незащищенными данными равноправны.

Неверное выражение — среднее воздействие. Само собой, расставьте скобки, как вам заблагорассудится — что тут такого.

Ошибки одновременного доступа — среднее воздействие. Подумаешь, проковыряешься с их отладкой всю оставшуюся жизнь, ничего страшного.

Ошибки использования API — среднее воздействие. Ваш код ошибочно забывает указать путь, и это приводит к удалению всего, что находится в директории WindowsSystem32. Тоже мне, ошибка.

Зависание программы — среднее воздействие. Программа виснет только тогда, когда ее запускают на компьютере вне сети Windows NT. У вас все работает прекрасно, пока вы гоняете ее внутри своей корпоративной сети, потом едете на выставку, и она перестает работать, а ваш ноутбук превращается в радиатор с экраном за тысячу долларов. Ерунда.

Интересно, почему ни одной категории не присвоена степень слабого воздействия? Может быть, авторы не решились приписать низкий уровень воздействия программной ошибке просто потому, что она входит в какую-либо группу?

Это не работает. Нельзя разбросать несколько тысяч ошибок по нескольким категориям, а последним присвоить степень воздействия. Это просто невозможно. Если вы разработчик ПО, вы должны принять это без тени сомнения, а иначе — лучше сразу же увольтесь и отправляйтесь в ближайший Макдональдс — для вас у них есть вывеска «требуются работники».

Весь этот Отчет о проверке целостности — всего лишь сплошная мешанина чисел и диаграмм, а ее полезность даже не нулевая — она отрицательная. Этот отчет перепугает насмерть любого, кто заботится о качестве ПО и решит ознакомиться с документом.

Результаты

Итак, какая же разница между коммерческими материалами PVS-Studio и Coverity? Первые представляют вам факты, которые можно интерпретировать и проверять. Вторые просто пытаются напугать вас обобщенными данными и не предоставляют никакой возможности проверить их.

Потому что не каждый заслуживает бесплатной пробной версии Coverity.

PVS-Studio должен быть у тех, кто заботится о качестве кода

Автор: Адам Савицки ^[26]

Источник: цитата из статьи "Статический анализ C++ кода с помощью PVS-Studio ^[27]" (EN).

В целом PVS-Studio выглядит как добротный инструмент для C++ программистов, которые заботятся о качестве своего кода. Поиск проблем, связанных с OpenMP и 64-битной совместимостью, может оказаться очень полезным для тех, кому нужны такие возможности.

Очень плохо, что PVS-Studio, в противоположность Cppcheck, является плагином Visual Studio, а не самостоятельным приложением, так что он однозначно требует наличия у вас коммерческой версии MSVS и при этом не работает в Express издании. Но это можно понять — если вам нужны OpenMP или 64-бита, вы, возможно, уже используете версию Visual Studio Professional или лучше.

Кратко: PVS-Studio замечательный инструмент

Автор: Флориан Джордж (работает программистом с 2009 года в компании, занимающейся анализом машинного зрения и компьютерных изображений)

Источник: письмо, в котором человек отвечает нам на просьбу дать оценку анализатору PVS-Studio.

Я очень впечатлен PVS-Studio.

У вас уже имеется большая база, и вы можете отлавливать намного больше ошибок, чем, скажем, /analyze и Cppcheck. Кроме того, если взглянуть на лог изменений, она часто обновляется. Мне очень нравится, что для каждой ошибки даются детальные пояснения с примерами и рекомендациями, как их исправить. Правда иногда я не очень понимаю смысл проблемы и как ее поправить. Думаю, будет полезно, если вы дадите вашим клиентам, или даже просто посетителям, возможность писать комментарии в специальной форме внизу страницы для каждой ошибки, где они смогут рассказать, насколько правильно они поняли описание ошибки и помогло ли оно им успешно исправить ее в своем коде, а если нет, то они предоставили бы вам код, который, в свою очередь, поможет вам улучшить описание объяснений ошибок в сообщениях. Для начала, может быть, сойдет даже возможность оставлять комментарии на страницах документации по ошибкам.

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

Интеграция со средой Visual Studio превосходна, все работает, как надо. Функция «click to jump to the code» очень удобна, так что неудивительно, что именно она взята в качестве отличительной возможности полной версии по сравнению с пробной.

Я наткнулся на статический анализ кода случайно и с тех пор прочитал большое количество заметок в вашем блоге (классные заметки!), а также статьи по AltDevBlog, Random ASCII и т.д., в результате чего очень заинтересовался предметом.

Я работаю в небольшой компании из 10 человек. К сожалению, я не могу убедить начальника заплатить несколько тысяч долларов за ПО, выгода от которого лично для него проявится не сразу. То же самое произошло, когда я предложил приобрести лицензию на Vtune. Так что сейчас я привязан к пробной версии и обхожусь ручной навигацией, как было предложено в одном из постов в блоге, но в то же время это очень неудобно при регулярном применении. Мне кажется, вы столкнулись с ситуацией (с чем-то подобным, возможно, сталкиваются многие другие люди, заинтересованные в PVS-Studio), которая и смешная, и грустная одновременно — есть люди, которым нравится то, что вы делаете, но по определенным причинам они не могут пойти и купить полную версию.

У вас замечательный продукт по очень выгодной цене по сравнению с остальными профессиональными решениями. Мне бы хотелось, чтобы вы сделали скачок в сторону более широкой массовой аудитории. На данный момент только боязнь людей пропустить «последнее предложение», в основном в отношении цен, как мне кажется, может заставить их купить продукт не раздумывая, подобно тому, как мы кидаемся покупать игру в Steam, как только увидим недельную скидку на нее.

Надеюсь, это письмо дало вам некоторое понимание того, как PVS-Studio воспринимают здесь у нас. Продолжайте так же хорошо делать свою работу!

Ложка дёгтя

Конечно, нам попадаются и менее положительные отзывы, наподобие этого ^[28] (RU). Мы не стали рассказывать о них, не из-за желания приукрасить PVS-Studio. Многие из указанных в отзывах недостатков уже устранены или мы работаем над ними. Например, нет смысла рассказывать об отзыве, где написано, что PVS-Studio совершенно не умеет отлавливать нулевые указатели. Сейчас это является неправдой. В анализаторе уже появилось несколько диагностик на данную тему.

Также, много отрицательных отзывов связано с медленной скоростью работы PVS-Studio. Но, когда мы начинаем выяснять причины, то оказывается, что, как правило, виноват не он. Например, проект находится на сетевом диске. Тогда анализ выполняется очень медленно, так как в процессе работы генерируются большие препроцессированные *.i файлы. Другой пример. PVS-Studio.exe (и препроцессор Clang) запускается параллельно множество раз. И часто замедление вносит антивирус, бессмысленно вновь и вновь проверяя эти исполняемые модули. Предлагаю познакомиться со статьёй "Советы по повышению скорости работы PVS-Studio ^[29]".

Автор: Andrey2008