Анализатор PVS-Studio умеет "схлопывать" повторяющиеся предупреждения. Предоставляет возможность задать baseline, что позволяет легко внедрять статический анализ в legacy-проекты. Стоит ли предоставить эти возможности для сторонних отчётов?
Эта статья появилась после чтения некоторых вопросов на сайте Stack Overflow, посвящённых удобной работе с отчётами статических анализаторов. Возможно, есть смысл поддержать работу с этими сторонними отчётами через интерфейс PVS-Studio.
Вначале я просто хотел обсудить эту тему с коллегами на одном из собраний. Но потом понял, что обсуждение получится абстрактное без предварительного изучения интереса пользователей к этой теме. Поэтому я и пишу эту статью, чтобы собрать фидбек. Буду благодарен за комментарии.
Дубликаты сообщений
С самой первой версии анализатор PVS-Studio (тогда он назвался Viva64) умел отфильтровывать дубликаты сообщений. С самого начала было понятно, что это крайне важный функционал, если анализируется C или C++ программа.
Впервые я познакомился с инструментом статического анализа 2006 году. Это был PC-Lint, и меня невероятно раздражали отчёты с бесконечным повтором предупреждений. Не знаю, как сейчас с этим обстоят дела в PC-Lint, не смотрел, но тогда было именно так.
Дубликаты возникают, когда линтеры ругаются на что-то в заголовочном файле. Вы получаете идентичное предупреждение каждый раз, когда проверяется .c/.cpp файл, включающий этот заголовочный .h-файл.
Иногда повторяются предупреждения и в .c/.cpp файлах, если один и тот же файл включён в разные проекты какого-то большого решения. Это более редкий сценарий, но он тоже имеет место быть.
Когда мы начали разрабатывать первый плагин PVS-Studio для Visual Studio 2005, в нём уже отбрасывались повторяющиеся сообщения. Аналогично действуют все наши существующие на данный момент плагины и утилиты конвертации.
А что я вижу, заглядывая на StackOverlow? Вопросы, как убрать дубликаты! Вот для примера одна из свежих дискуссий: How to avoid duplicate clang-tidy warnings coming from the same header?
Recently I started using clang-tidy in a C++ project and I encountered an annoying problem. When a header contains error and is included in many .cpp files the error is reported multiple times by clang-tidy. Obviously the error is found in different .cpp files, but in fact the error is inside the header and I would like to see just one error message. Is it possible and how could it be done?
BTW: I am aware that a similar question has been asked here. However, the answer is not correct and the problem is not in invoking clang-tidy as a CMake target.
Оказывается, годы прошли, а линтеры так и не предоставляют базовый уровень комфорта для разработчика.
Я не говорю, что проблема серьёзна. Можно придумать массу способов, как исправить ситуацию. Например, можно использовать в качестве агрегатора сообщений SonarQube. Этот инструмент умеет "схлопнуть" дубликаты и вообще предоставляет различные способы интерактивной работы с отчётами.
Тем не менее, раз вопросы на StackOverlow есть, то значит есть и проблема.
Baseline
Другая важная вещь, которую мы сделали в PVS-Studio, – массовое подавление предупреждений. Она позволяет быстро внедрить статический анализатор даже в большой проект.
Подробно всё это описано в статье "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду". Здесь же я кратко перескажу основную суть.
Пользователь запускает анализатор и получает множество предупреждений. Допустим, проект, разрабатываемый много лет, тестируется и приносит деньги. Вряд ли для такого проекта будет выдано много предупреждений, указывающих на критические дефекты. Критические баги так или иначе уже поправлены более дорогими способами или благодаря фидбеку от клиентов. Соответственно, всё, что находит анализатор на этапе внедрения, можно считать техническим долгом, который практично устранить постепенно, а не сразу.
Можно указать PVS-Studio считать эти предупреждения пока неактуальными (отложить технический долг на потом), и он больше не будет их показывать. Анализатор создаёт специальный файл, где сохраняет информацию о тех ошибках, которые пока отмечены как неинтересные. Далее PVS-Studio будет выдавать предупреждения только на новый или изменённый код. Причём всё продумано. Если, например, в начало файла с исходным кодом будет добавлена пустая строка, то анализатор понимает, что, по сути, ничего не изменилось, и по-прежнему будет молчать. Файл с информацией о подавлениях можно заложить в систему контроля версий. Файл большой, но это не страшно, так как часто его закладывать смысла нет.
Теперь все программисты будут видеть предупреждения, относящиеся только к новому или изменённому коду. Таким образом, анализатор можно начать использовать, что называется, со следующего дня. А к техническому долгу можно будет вернуться позднее, постепенно исправлять ошибки и настраивать анализатор.
Итак, в PVS-Studio тема внедрения в проект проработана. А что я вижу на Stack Overflow? Я вижу, например, следующий вопрос: How to monitor new warnings in code generated by error checking tools?
Do generic tools exist for keeping track of warnings in code?
Some static-analysis tools generate a large number of false-positive warnings, so changing the code isn't desirable. Disabling individual warnings isn't always a practical option either.
Do tools exist that take a list of locations in a file (which could be generated from static analysis tools), which could be run on a regular basis to detect the introduction of new warnings?
Even though diffing the outputs works on a basic level, it would be more useful if changes to line-numbers for example could be done without re-raising the warnings to the developers attention — every time the file was modified.
Опять-таки можно воспользоваться таким инструментом, как SonarQube, и смотреть, какие новые предупреждения будут выдаваться. А можно подумать в сторону расширения возможностей PVS-Studio для поддержки сторонних источников предупреждений.
SonarQube
Мы не собираемся позиционировать себя как альтернативу SonarQube. Мы просто размышляем над тем, как упростить жизнь программистам, которые уже используют PVS-Studio. Чтобы они могли удобно работать не только с предупреждениями PVS-Studio, но и со сторонними источниками предупреждений.
Кстати, на всякий случай напомню, что PVS-Studio сам может являться источником данных для SonarQube. Подробнее про это можно почитать здесь. Так что если вы уже используете SonarQube, то лучше пусть он агрегирует все предупреждения.
Что думаете?
В мире имеется запрос на фильтрацию предупреждений с точки зрения повторений и для отслеживания новых срабатываний. У нас есть три варианта, как мы можем поступить:
- Ничего не делать. Сделаем вид, что никаких проблем нет. Ну или по крайней мере, что это к нам никак не относится. От такого выбора никого профита ни нам, ни программистам. Зато и делать ничего не надо :).
- Написать статью, где рассмотреть различные варианты решения этих проблем. Например, описать, как можно использовать для этого тот же SonarQube.
- Сделать возможность импорта сторонних предупреждений в PVS-Studio для дальнейшей удобной работы с ними. Например, можно "подхватывать" предупреждения, выдаваемые clang-tidy.
Как вы понимаете, эта статья написана, чтобы поговорить про третий вариант.
Что, если плагины и конверторы отчётов, входящие в состав PVS-Studio, будут работать не только с собственными предупреждениями, но и с внешними? Вам будет полезна такая функциональность?
Прошу написать в комментариях, что вы думаете про это. Спасибо.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. Should PVS-Studio process other tools' reports?.
