«Разработчики PVS-Studio, вы вообще слышали про Clang?», или сравнение PVS-Studio и Clang без кода

в 10:49, , рубрики: clang, pvs-studio, Блог компании PVS-Studio, статический анализ, статический анализ кода, метки: , , ,

Довольно часто, когда мы пишем статьи про статический анализатор C++ кода PVS-Studio, нам задают один из следующих вопросов:

  1. А чем PVS-Studio лучше, чем Clang?
  2. А вот Clang бесплатный, а вы стоите денег – не понятно, почему?
  3. Clang лучше, туда легко можно добавить свои диагностики, ведь это open source!
  4. Вам пора закрываться, Clang вас раздавит, если не сейчас, то когда отладят версию под Windows.(ну это даже и не как вопрос сформулировано).

Пришло время обстоятельно ответить на эти вопросы.

Начну с небольшой шутки. PVS-Studio лучше чем Clang хотя бы тем, что PVS-Studio в коде Clang находил ошибки (раз, два), а Clang в коде PVS-Studio – нет.

Сравнить инструменты анализа кода, непростая задача (я уже писал на эту тему). Некорректно сравнивать инструменты статического анализа только по набору диагностических правил. Ведь в обычной жизни инструменты используются не в тестах, а в реальных проектах. И тогда оказывается, что у инструмента статического анализа есть две фазы – внедрение в существующий проект и регулярное использование.

Давайте рассмотрим, как человек пробует, к примеру, Clang. Возможно, человек берет несколько маленьких тестовых файлов с программными ошибками, запускает на них анализатор и видит, что что-то анализатор нашел, что-то не нашел. Предположим, человеку понравились сработавшие диагностики. После этого он пробует анализатор на своем реальном проекте и видит сотни, а то и тысячи сообщений от анализатора кода. Исправить их все сразу он не может, что-то с ними сделать – непонятно что, ведь анализатор типа Clang их просто выведет в консоль. Именно в этот момент и должно начинаться внедрение анализатора.

Цель этапа внедрения статического анализа в существующий (а значит большой) проект – получить при запуске анализатора на код 0 диагностических сообщений. И вот тут оказывается, что Clang ничего не может предложить. В нем просто нет механизмов для того, чтобы работать с большим количеством сообщений. Ну кроме как вручную пройти по каждому сообщений и внести правки при необходимости.

Что же может предложить PVS-Studio? Очень многое:

  1. Исключение из анализа отдельных файлов, файлов по маске или папок.
  2. Фильтрация сообщений по коду ошибки или содержимому сообщения.
  3. Различные способы сортировки сообщений.
  4. Разметка сообщений ка ложное срабатывание (False Alarm) для их дальнейшего сокрытия.
  5. И многое другое.

Ключевой момент – что все эти функции работают в режиме реального времени без необходимости перезапуска анализа. Это очень важно, так как на больших проектах код может проверяться достаточно долго.

Почему у PVS-Studio есть такие возможности по упрощению этапа внедрения, а у Clang их нет? Дело в том, что представление результатов анализа в PVS-Studio – это таблица (как на рисунке):

Рисунок 1 – Представление результатов анализа PVS-Studio.
Рисунок 1 – Представление результатов анализа PVS-Studio.

Точнее таблица – это визуальное представление, а внутри это база данных, со всеми вытекающими возможностями по фильтрации и обработке этих данных. В случае же clang это вывод в консоль. Конечно, при интеграции clang в среду разработки мы получаем навигацию, но не более того. А это значит, что мы подходим к главному отличию PVS-Studio от Clang.

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

Может показаться, что я сознательно избегаю сравнения PVS-Studio и Clang по уровню диагностик. И да, и нет. Задача сравнения диагностических возможностей инструментов сложна сама по себе. Но более того, результаты такого сравнения очень быстро устаревают. И мы, работая над PVS-Studio, и разработчики Clang – все добавляют новые диагностики.

Если кто-то говорит: «Я запускаю clang и у меня 0 диагностик, хотя никакого внедрения я не делал», то этот человек просто пользуется уже внедренным инструментом. Вот и все.

Теперь к вопросу о том, почему Clang бесплатный, а PVS-Studio стоит денег. Программисты не всегда задумываются над тем, из каких средств они получают зарплату. Над Clang работают программисты из Apple, Google, Intel. Мы же развиваем PVS-Studio как независимый проект и вынуждены зарабатывать себе зарплату сами, поэтому PVS-Studio платный продукт. Естественно мы никого не обязываем им пользоваться. Наши клиенты – это те пользователи PVS-Studio которым этот продукт нужен и которые понимают «за что тут платить».

Хотя анализатор в Clang является open source проектом, добавить в него новое диагностическое правило человеку, который не является экспертом в области анализа кода, будет довольно сложно. Но тут верить на слово не стоит, просто попробуйте добавить новое правило в Clang, если это вам актуально.

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

Впрочем, этот текст не означает, что мы как-то плохо относимся к Clang. Это очень хороший проект, часть которого используется в PVS-Studio (в качестве препроцессора), и над ним работает очень большое количество классных разработчиков.

Автор: EvgeniyRyzhkov

Источник

Поделиться

* - обязательные к заполнению поля