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

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

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

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

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

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

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


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

>
>
Как быстро внедрить статический анализ …

Как быстро внедрить статический анализ в большой проект?

08 Мар 2015

Итак, вы – разработчик в проекте, в котором много (или даже очень много) исходного кода. Например, более 100 мегабайт.

0309_Message_Suppression_howto_ru/image1.png

Вы начитались статей про проверку open source проектов и захотели проверить свой собственный проект каким-нибудь анализатором кода. Вы проверили проект и получили более тысячи сообщений от анализатора. Тысяча – это оптимистичный вариант. Может быть и более десятка тысяч. Но вы же не ленивый разработчик? Вы начали просматривать их. И, о ужас, уже пятое сообщение анализатора оказалось реальной ошибкой! А также седьмое, девятое, двенадцатое и пятнадцатое. Вы выписали себе еще десяток реальных ошибок, на которые указал анализатор и направляетесь к боссу со словами:

"Шеф, смотри. Я скачал крутой анализатор. Он нам уже только за полчаса нашел десять реальных ошибок. А всего он выдал тысячу (две, три, четыре) сообщений. Давай купим этот анализатор, мы с ребятами займемся и все сообщения поправим за две-три недели. И потом, когда все поправим, он нам будет выдавать 0 сообщений. А значит мы – крутые программисты и делаем качественный код!"

И хотя вы уже мысленно подставляете грудь для новой медали (ведь вы радеете за качество проекта!), шеф ваш очень вероятно ответит примерно так:

"Тебе что, заняться нечем? Ты всю команду хочешь на три недели отвлечь для правки ошибок, а у нас релиз через месяц! Ну и что, что ошибки реальные? Жили как-то с ними и ничего. Да, я понимаю, что было бы здорово не делать ошибки в новом коде. Ну так вы и не делайте! А старый код трогать не позволю! Он уже оттестирован и клиенты за него заплатили. А кто за три недели работы команды платить будет? Так что не будем мы покупать анализатор, да и код старый трогать не будем. А у тебя видимо текущие задачи кончились. Так мы сейчас тебе подкинем. И чтобы завтра готово было!"

Реальный сценарий? Реальный. Хуже всего то, что хорошая идея внедрения статического анализа заглохла от того, чтоб надо проработать все сообщения, которые выдает анализатор кода. Ведь если каждый прогон анализатора будет выдавать тысячу сообщений, то понять, где новые сообщения, а где старые будет невозможно. Или все-таки есть способ решить эту проблему?

Как этот вопрос решает в PVS-Studio?

Пару релизов назад в PVS-Studio появился механизм для подавления старых или "неинтересных" сообщений от анализатора кода. К версии 5.22 мы его окончательно отладили, отработали и теперь он оказался настолько удобным, что мы его рекомендуем использовать всем, кто задумывается о внедрении статического анализа в своем проекте. А я сейчас расскажу, как этим пользоваться.

Итак, перед вами проект на 5 миллионов строк кода (всего лишь для примера), в котором 150 мегабайт исходников. Вы проверили его анализатором и получили несколько тысяч сообщений общего назначения (General Analysis). Вы и рады бы их исправить, да времени менеджер проекта не выделяет.

OK, не вопрос. После завершения анализа всего солюшена идем в меню PVS-Studio -> Suppress Messages... Диалог простой, нажимаем "Suppress Current Messages", затем Close. В итоге у вас окне PVS-Studio останется 0 сообщений. И даже если вы запустите еще раз анализ всего кода – после завершения анализа будет 0 сообщений. Зато вот если вы начнете писать новый код или модифицировать старый, то на этот код анализатор уже будет ругаться. Если, конечно, вы не напишете его сразу идеальным.

Как это работает?

Работает данный механизм довольно просто. Вернее, сейчас это просто, но сколько экспериментов было поставлено, чтобы прийти к такому варианту... Ну да ладно, что же происходит с точки зрения пользователя, когда он нажимает кнопку "Suppress Current Messages"?

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

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

Что делать с этими. suppress файлами? Если PVS-Studio запускается на одной машине, скажем билд-сервере, то можно хранить эти файлы прямо в папках проектов. Если это не удобно (например, делается чистая сборка), то перед запуском анализатора можно копировать файлы в папку проекта с помощью robocopy из другого места – он сохраняет структуру папок.

Если с анализатором работают несколько разработчиков, то .suppress-файлы можно заложить в репозиторий. Возникает вопрос – а как синхронизировать эти .suppress файлы между разработчиками? С одной стороны ответ прост – это XML, так что нет проблем. Но с другой стороны оказывается, что синхронизировать эти файлы (да и вообще как-то их модифицировать) и не надо. Достаточно один раз при внедрении анализатора их создать, а больше их модифицировать не зачем. Ну и стараться при этом поддерживать 0 сообщений от анализатора на проекте в дальнейшем.

Примечание. А как же поддерживать 0 сообщений от анализатора в дальнейшем, если он нет, нет, да и выдаёт ложные предупреждения? На этот случай есть несколько способов для подавления отдельных предупреждений. Про этот будет сказано ниже.

Ну и для чего этот механизм?

Если вдруг кто-то еще не понял, то приведу абсолютно конкретный пример. Можно добавить все сообщения в такую базу (получим 0 сообщений при проверке). Дальше на билд-сервере каждую ночь запускается анализатор (как настроить запуск анализатора на билд-сервере), который выдает только новые сообщения, то есть сообщения на новый код, написанный командой за день. Эти сообщения сохраняются не только в .plog (отчет анализатора в xml-формате), но в текстовый файл рядом. А этот текстовый файл уже можно рассылать по почте участникам проекта с помощью любой подходящей программы. Например, с помощью SendEmail.

Утром люди видят сообщения от анализатора в своей почте и могут править ошибки даже без установки PVS-Studio на свои машины. Ну а если все-таки хочется отрыть отчет (.plog), то он доступен на билд-сервере. С помощью этого трюка можно здорово сэкономить на лицензиях на PVS-Studio.

Кстати вы можете настроить какие сообщения (точнее каких уровней) должны попадать в текстовый отчет. Это делается с помощью опции OutputLogFilter, которая находится на вкладке Specific Analyzer Settings настроек PVS-Studio. Мы рекомендуем включать в текстовый файл сообщения General Analysis Level1 и Level 2.

Небольшая оговорка про инкрементальный анализ

Мы все-таки рекомендуем прежде всего разработчикам использовать PVS-Studio в том числе и на локальных машинах в режиме инкрементального анализа. Речь идет о галочке "Analysis after Build (Modified files only)" в меню PVS-Studio. При включенной галочке анализатор следит за вашей работой и автоматически запускается для тех файлов, которые были скомпилированы (отслеживает модификацию .obj-файлов). Если анализатор ничего не найдет – то вы даже не заметите, что он запускался. А если найдет, то будет всплывающее сообщение об ошибках.

Инкрементальный анализ поддерживает базу "неинтересных" сообщений. Если у вас такая база есть, то сообщения от инкрементального анализа будут только про новый код. А если нет, то полностью на файл, который анализируется.

Режим инкрементального анализа позволяет исправлять ошибки сразу же при их появлении, еще до того, как ошибка окажется в системе контроля версий. А как известно из Макконнелла, исправление ошибок на этом этапе самое дешевое. Поэтому при наличии возможности мы рекомендуем использовать PVS-Studio и при ежедневных проверках на сервере, и в режиме инкрементального анализа на машинах программистов.

Как поправить сообщения, находящиеся в базе?

Хорошо, вы внедрили статический анализ на проекте, анализатор выдает вам не более нескольких сообщений в день, которые вы с командой сразу же правите. Отлично. Но тут выдалась неделька свободного времени, которое можно потратить на правку старых ошибок. Как до них добраться? Есть два варианта.

  • Вы можете через команду "Suppress Messages..." вызвать диалоговое окно, в котором появится галочка "Display Suppressed Messages". Включите ее и появятся сообщения.
  • Либо, если у вас настроен ежедневный запуск на билд-сервере, то вы просто идете в папку с результатами последнего анализа и видите там следующие файлы:
    • SolutionName.plog – лог с только новыми сообщениями;
    • SolutionName.plog.txt – текстовый лог, тоже самое что и SolutionName.plog;
    • SolutionName_WithSuppressedMessages.plog – все сообщения, включая "неинтересные".

Вот с этим файлом SolutionName_WithSuppressedMessages.plog и надо работать. Открываете его и получаете все сообщения. В первое время этот файл будет большой, так как сообщений много. Но если вы их хотя бы иногда будете править, то со временем он станет маленький, а может и вовсе вы от него сможете отказаться (и от .suppress-файлов соответственно тоже).

Важно понять вот что. Если у вас появляется время и возможность, вы всегда можете вернуться к старым "неинтересным" сообщениям и поправить их. Мы рекомендуем это делать, так как все-таки ошибки есть ошибки и их надо править.

А это не противоречит функции Mark as False Alarm?

В PVS-Studio есть команда Mark As False Alarm – разметить как ложное срабатывание. Это когда в строку с сообщением добавляется комментарий вида //-V501. Встретив такой комментарий анализатор не будет выдавать сообщение V501 на эту строку.

Механизм, описываемый в этой статье и Mark As False Alarm никак не противоречат друг другу. Но они служат для немного разных целей. Массовое подавление неинтересных сообщений – для массовой разметки при внедрении анализатора в проект. А Mark As False Alarm – для того, чтобы анализатор не ругался на отдельные фрагменты.

В принципе можно было бы и раньше разметить весь код как False Alarm, но обычно людям страшновато делать столько много правок в коде. Кроме того, не понятно, как работать со старыми ошибками – убирать все, что размечено как False Alarm? А если там действительно false alarm.

Но и использовать механизм массового подавления для подавления отдельных сообщений тоже неправильно.

В общем это два механизма, решающих разные задачи. Не надо их путать.

Заключение

Итак, подход к внедрению статического анализа в живом проекте выглядит так:

  • Размечаем все сообщения как "неинтересные" с помощью команды "Suppress Messages...".
  • Теперь при следующем запуске анализатор будет выдавать сообщения только на новый код.
  • При необходимости всегда можно исправить ошибки, которые были скрыты при внедрении.

Это позволяет начать получать пользу от статического анализа сразу же.

Дополнительные ссылки

Популярные статьи по теме
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

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

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

Дата: 31 Июл 2017

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

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

Дата: 16 Окт 2017

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

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

Дата: 27 Июн 2017

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

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

Дата: 22 Дек 2018

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

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

Дата: 30 Янв 2019

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

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

Дата: 20 Мар 2017

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

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

Дата: 14 Апр 2016

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

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

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

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
PVS-Studio для Java

Дата: 17 Янв 2019

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

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

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

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