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

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

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

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


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

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

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

2 июля 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 для тех, кто развивает открытые проекты

Дата: 22.12.2018

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

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
PVS-Studio ROI

Дата: 30.01.2019

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

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20.03.2017

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

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14.04.2016

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

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31.07.2017

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

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

Дата: 22.10.2018

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

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

Дата: 16.10.2017

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

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

Дата: 27.06.2017

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

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
Эффект последней строки

Дата: 31.05.2014

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

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
PVS-Studio для Java

Дата: 17.01.2019

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

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…

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

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять