metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

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

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

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

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

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

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


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

Вебинар: Трудности при интеграции SAST, как с ними справляться - 04.04

>
>
Зачем понадобилась система подавления с…

Зачем понадобилась система подавления сообщений статического анализатора

04 Дек 2014

Каждый программный продукт имеет свою историю происхождения и развития. Проект может быть новым и небольшим или быть коммерчески успешным десяток лет и иметь тысячи исходных файлов. При внедрении статического анализатора, кроме технического вопроса интеграции в проект, возникают и другие немаловажные вопросы: как правильно обрабатывать результаты анализа? Стоит ли править все предупреждения анализатора? ... В данной статье будет рассказано о новом способе обработки результатов работы статических анализаторов.

0294_Suppresser_ru/image1.png

Роль стандартного статического анализатора кода выполняет используемый компилятор. Небольшой ряд его диагностических правил охватывает только самые распространённые случаи подозрительного написания кода, почти все из которых не просто рекомендуется исправлять, а являются обязательными для исправления во многих компаниях.

Тем не менее, сообщений компилятора генерируется не так много, среди которых не составит труда увидеть новое предупреждение и при необходимости его исправить. Специализированные же статические анализаторы имеют множество диагностических правил и даже на малых проектах могут генерировать огромное количество предупреждений.

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

Отключение подобных диагностических правил не является хорошим решением. С помощью них можно обнаружить ошибки, которые крайне сложно заметить при обзоре кода. И, несмотря на ложные срабатывания, реальная ошибка в дальнейшем может появиться. Тогда встаёт вопрос, как пропускать некоторые предупреждения и видеть только новые.

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

Таким образом, потребовалась возможность подавления сообщений статических анализаторов кода на больших проектах. Было необходимо выделять новые предупреждения среди всех, основываясь только на предыдущих запусках анализатора.

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

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

В статическом анализаторе PVS-Studio использование данного функционала реализовано в виде диалогового окна "Analyzer Message Suppression" (рис. 1).

0294_Suppresser_ru/image2.png

Рисунок 1 - Диалоговое окно управления подавлением предупреждений

Кнопка "Suppress Current Messages" выполняет первоначальную разметку сообщений анализатора и сохраняет результат в локальные *.suppress файлы. После чего, при последующих проверках исходного кода, полученные сообщения будут сопоставляться с сообщениями из этих файлов и в окне вывода IDE плагина PVS-Studio будут отображаться только новые предупреждения (рис. 2).

0294_Suppresser_ru/image3.png

Рисунок 2 - Несколько новых предупреждений анализатора

Галочка "Display Suppressed Messages in PVS-Studio Output Window" рисунке 1 позволяет включить отображение в окне вывода PVS-Studio и отфильтрованных сообщений, статус которых можно при необходимости изменить (рис. 3).

0294_Suppresser_ru/image5.png

Рисунок 3 - Все предупреждения анализатора

Заключение

Новый механизм, реализованный в статическом анализаторе PVS-Studio, является дополнением к существующему способу разметки комментариями исходного кода. Если ложное предупреждение указывает на строчку в заголовочном файле, который включается во многие исходные файлы и разные проекты, то такое место лучше один раз разметить комментарием. Благодаря таким возможностям, регулярное использование статического анализа становится удобнее в использовании.

Популярные статьи по теме


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

Следующие комментарии next comments
close comment form