Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода

Андрей Карпов
Статей: 371



Время от времени нас спрашивают: сравнивали ли мы PVS-Studio с другими статическими анализаторами кода и можно ли про это почитать? Мы отвечаем, что такого сравнения нет и мы не сможем написать статью на эту тему. Причина не в нашей лени или в том, что мы боимся сравнивать наш анализатор с другими решениями. Отсутствие сравнения вызвано тремя причинами, которые будут рассмотрены в этой статье и с которыми мы мало что можем сделать. Как говорится, расставим все точки над i.

Picture 1

Почему мы не пишем статьи, сравнивающие наш анализатор с другими инструментами

1. Недоверие к таким статьям

Много лет назад мы пробовали писать подобные статьи (пример). Причем подходили к этому весьма ответственно. Мы брали набор проектов, проверяли их различными анализаторами кода и смотрели, какой анализатор найдёт больше настоящих ошибок. Это тяжелый труд просматривать все эти отчёты, отнимающий более сотни человеко-часов. После чего оформляли наши исследования в виде статей. Читатели были признательны проведённым нами исследованиям? Отнюдь. Каждый раз мы получали лавину критики, сводившуюся в целом к следующей мысли: мы специально так выбрали проекты, чтобы показать лучший результат.

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

Что интересно, непонятно как работать с критикой. Ведь действительно, как аудитории удостовериться, что наша команда выбирала проекты на GitHub случайным образом? Я не знаю ответа. Некоторые читатели высказывали идею, что такая статья должна быть написана независимым человеком. Идея хорошая, но не понятно, как её реализовать. Где взять этого самого энтузиаста, который на добровольной основе займётся подробным сравнением анализаторов, проверив ряд проектов? Да, можно кому-то заплатить за эту работу. Но тогда вновь встаёт вопрос: можно ли доверять статье, написанной за наши деньги? Получается, что мы вернулись к тому, с чего начали :).

2. Компании не идут на контакт

Если речь идёт о сравнении проприетарных продуктов, то, чтобы что-то сравнивать, эти продукты нужно получить в распоряжение. А это не так просто, как может показаться на первый взгляд. Например, некоторые компании просто "исчезают" и игнорируют все мои запросы на получение демонстрационной версии, когда узнают, кто мы :). Ну не обманывать же их, чтобы получить доступ к продукту? Я даже не уверен, что мы сможем купить при желании эти продукты.

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

3. Юридическая сторона вопроса

Законодательства некоторых стран, в целях препятствия недобросовестной рекламе, запрещают прямое сравнение двух продуктов. Можно писать, что умеет один продукт, что другой, и представлять таблицы, по которым читатель должен сам делать сравнение и выводы. Но нельзя написать, что один продукт хороший, а другой плохой. И вот тут я не знаю, как написать, что один продукт нашел 100 багов, а другой 10, но при этом не сделать вывод, что первый лучше второго :).

Понятно, что всё это можно аккуратно сделать и написать корректную статью. Однако мы ещё небольшая компания (на момент написания заметки в штате компании 31 сотрудник). И у нас нет отдела юристов, которые всё это выверят и сделают материал защищённым от каких-либо претензий. Раз так, то это лишний повод не связываться с вопросом непосредственного сравнения нашего анализатора с конкурентами. Лучше потратить силы на то, чтобы анализатор PVS-Studio начал использовать ещё более продвинутые технологии анализа кода.

Так как же быть?

Тем не менее, как же понять, достоин анализатор PVS-Studio стать частью вашего DevOps?

Всё очень просто. Запустите статический анализатор PVS-Studio на коде вашего проекта и посмотрите результаты.

Только не включайте все диагностики сразу. Иначе вы заблудитесь в предупреждениях, нерелевантных для вашего проекта. Начните с General (GA) предупреждений первого уровня достоверности. Чуть подробнее про это рассказано здесь.

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

Многие ошибки найдутся в редко используемом или вообще неиспользуемом коде. Надо правильно интерпретировать это наблюдение. Наиболее значимые ошибки в старом коде уже исправлены. Другие ошибки не влияют на работу программы, и они-то как раз массово и выявляются при первых запусках анализатора. При этом затраты на серьезные исправленные ошибки были гораздо выше, чем если бы они находились статическим анализатором ещё на этапе написания кода. Да, не все эти ошибки могут быть выявлены статическим анализом. Однако, если половина этих багов будет выявляться сразу, это существенно сократит время на их исправление и сократит затраты на разработку и сопровождение программного продукта. См. также статью "У нас 100 программистов, анализатор нашел мало ошибок, он бесполезен?".

Если ваша команда уже использует какой-то анализатор кода, то так даже ещё интереснее. Вы увидите, какие ошибки смог заметить PVS-Studio в проекте, который уже подвергается анализу с помощью других инструментов. Кстати, иногда мы пишем статьи о проверке открытых проектов, которые уже чем-то проверяются. Примеры некоторых таких публикаций:

Читатели могут справедливо заметить:

То, что ваш анализатор нашёл ошибки после инструмента XXX, не означает, что он лучше. Возможно, если бы проект изначально проверялся с помощью PVS-Studio, а затем кто-то запустил бы XXX, он также бы выявил ошибки, которые не находит PVS-Studio.

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

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

Скачайте и попробуйте PVS-Studio. Это лучший способ оценить его пользу и то, насколько хорошо он впишется в ваш процесс разработки. Если будут вопросы, то непременно обращайтесь к нам в поддержку. Мы поможем запустить и настроить анализатор, а в случае необходимости проведём его демонстрацию. Также мы оказываем очень качественную и быструю поддержку нашим клиентам (пример).

Узнать, насколько рационально использовать инструмент PVS-Studio, поможет статья "PVS-Studio ROI". Спасибо за внимание.



Найдите ошибки в своем C, C++, C# и Java коде

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

goto PVS-Studio;

Андрей Карпов
Статей: 371


Найденные ошибки

Проверено проектов
344
Собрано ошибок
12 970

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;