Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Почему мы не пишем о сравнении PVS-Stud…

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

02 Июл 2019

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

0637_No_PVS_Studio_Compare_ru/image1.png

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

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". Спасибо за внимание.

Популярные статьи по теме
Анализ потока данных PVS-Studio распутывает всё больше связанных переменных

Дата: 08 Авг 2022

Автор: Артём Ровенский

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

Дата: 02 Авг 2022

Автор: Сергей Васильев

Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно рабо…
Межмодульный анализ C и C++ проектов в деталях. Часть 2

Дата: 14 Июл 2022

Автор: Олег Лысый

В первой части статьи мы рассматривали основы теории компиляции C и C++ проектов, в частности особое внимание уделили алгоритмам компоновки и оптимизациям. Во второй части мы погрузимся глубже и пока…
Межмодульный анализ C и C++ проектов в деталях. Часть 1

Дата: 08 Июл 2022

Автор: Олег Лысый

Начиная с PVS-Studio 7.14, для C и C++ анализатора появилась поддержка межмодульного анализа. В этой статье, которая будет состоять из двух частей, мы расскажем, как устроены похожие механизмы в комп…
Эволюция PVS-Studio: анализ потока данных для связанных переменных

Дата: 28 Апр 2022

Автор: Никита Липилин

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

Комментарии (0)

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно. Хотите узнать подробнее?
Принять