Каждый программный продукт имеет свою историю происхождения и развития. Проект может быть новым и небольшим или быть коммерчески успешным десяток лет и иметь тысячи исходных файлов. При внедрении статического анализатора, кроме технического вопроса интеграции в проект, возникают и другие немаловажные вопросы: как правильно обрабатывать результаты анализа? Стоит ли править все предупреждения анализатора?… В данной статье будет рассказано о новом способе обработки результатов работы статических анализаторов.
Роль стандартного статического анализатора кода выполняет используемый компилятор. Небольшой ряд его диагностических правил охватывает только самые распространённые случаи подозрительного написания кода, почти все из которых не просто рекомендуется исправлять, а являются обязательными для исправления во многих компаниях.
Тем не менее, сообщений компилятора генерируется не так много, среди которых не составит труда увидеть новое предупреждение и при необходимости его исправить. Специализированные же статические анализаторы имеют множество диагностических правил и даже на малых проектах могут генерировать огромное количество предупреждений.
Сторонний статический анализатор кода не является инструментом, все предупреждения которого необходимо исправлять. Некоторые диагностические правила основаны на эвристических методах и нередко дают ложные срабатывания. Некоторые подозрительные места могут являться специальной задумкой программиста, написание кода имело свои причины и исправлять это место не планируется.
Отключение подобных диагностических правил не является хорошим решением. С помощью них можно обнаружить ошибки, которые крайне сложно заметить при обзоре кода. И, несмотря на ложные срабатывания, реальная ошибка в дальнейшем может появиться. Тогда встаёт вопрос, как пропускать некоторые предупреждения и видеть только новые.
В подобных ситуациях можно воспользоваться подавлением предупреждений, вписав соответствующий комментарий в конце строки, чтобы анализатор пропускал это место. Но такой способ зачастую вызывает недоверие, так как подразумевает автоматическую разметку большого объёма исходного кода, а о ручной разметке в крупных проектах не может быть и речи.
Таким образом, потребовалась возможность подавления сообщений статических анализаторов кода на больших проектах. Было необходимо выделять новые предупреждения среди всех, основываясь только на предыдущих запусках анализатора.
Одно диагностическое сообщение содержит в себе следующую информацию: название диагностики, тип и уровень предупреждения, поясняющее сообщение, имя проверенного файла, номер строки файла и хэш нескольких строк.
Для сопоставления предупреждений при изменении исходного кода необходимо учитывать все параметры диагностического сообщения, за исключением номера строки, т.к. он меняется непредсказуемо и при малейшей модификации файла.
В статическом анализаторе PVS-Studio использование данного функционала реализовано в виде диалогового окна «Analyzer Message Suppression» (рис. 1).
Кнопка «Suppress Current Messages» выполняет первоначальную разметку сообщений анализатора и сохраняет результат в локальные *.suppress файлы. После чего, при последующих проверках исходного кода, полученные сообщения будут сопоставляться с сообщениями из этих файлов и в окне вывода IDE плагина PVS-Studio будут отображаться только новые предупреждения (рис. 2).
Галочка «Display Suppressed Messages in PVS-Studio Output Window» рисунке 1 позволяет включить отображение в окне вывода PVS-Studio и отфильтрованных сообщений, статус которых можно при необходимости изменить (рис. 3).
Заключение
Новый механизм, реализованный в статическом анализаторе PVS-Studio, является дополнением к существующему способу разметки комментариями исходного кода. Если ложное предупреждение указывает на строчку в заголовочном файле, который включается во многие исходные файлы и разные проекты, то такое место лучше один раз разметить комментарием. Благодаря таким возможностям, регулярное использование статического анализа становится удобнее в использовании.
