как работать с выводом статического анализатора

Question

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

варианты, которые мы обсуждали до сих пор, следующие

1) нанять подрядчика, чтобы разобраться с предупреждениями и исправить их - его недостаток:вероятно, нам понадобятся очень опытные люди, чтобы внести все эти изменения, и ни один подрядчик не будет обладать необходимым пониманием кода.

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

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

итак, как же можно работать со статическим анализатором, не доводя текущие усилия по разработке до полной остановки?

Answer 1

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

• Проведите сортировку репрезентативной выборки дефектов, и если кажется, что средство проверки выдает не намного больше сигнала, чем шума, отключите его на данный момент.(Большинство средств проверки Coverity хороши, но никто не идеален, и, похоже, вам нужно безжалостно расставить приоритеты.)
  • В конечном счете, снова включите некоторые из этих средств проверки, но отметьте их в своих отчетах как низкоприоритетные.(Это сложнее, чем должно быть;Я давно утверждал, что Coverity нужно прочитать пару статей о ранжировании дефектов, написанных кем-то по имени Доусон Энглер.:-)
  • В еще более долгосрочной перспективе попробуйте средства проверки, которые по умолчанию отключены;некоторые из них обнаруживают впечатляющие ошибки.И предупреждения о разборе на удивление полезны, хотя вам нужно отключить некоторые поддельные предупреждения.
• Будьте цинично реалистичны в отношении того, какую часть вашей кодовой базы вы на самом деле собираетесь исправить в ближайшее время.Используйте компоненты, чтобы пропустить анализ кода, в котором вы не собираетесь исправлять дефекты, по крайней мере, на данный момент.(Например, теоретически, если ваш продукт содержит сторонний код, вы несете ответственность за его качество и должны исправлять в нем ошибки.На практике такие ошибки редко исправляются.И если это зрелый сторонний код, то частота ложноположительных результатов будет высокой.)
  • Настройка компонентов и исключение - сложная задача, но как только это сделано, они работают хорошо — одно из моих регулярных выражений с отрицательным прогнозом содержало более сотни дизъюнктов.
  • Компоненты также помогают в распределении индивидуальной ответственности за дефекты, что, как я обнаружил, имеет решающее значение для их устранения.
• Настройте отчет только для новых дефектов и попросите людей просмотреть этот URL-адрес.В активном коде появились новые дефекты, и проще начать работу с политикой Отсутствия новых предупреждений.

Позвольте мне закончить несколькими оговорками:

• Возможно, вы захотите повторно задать этот вопрос на форуме поддержки Coverity (http://forums.coverity.com/), который не очень активен, но где нам не нужно беспокоиться о нарушении NDA.У меня там есть список шашек, которые, по моему мнению, стоит включить.

• Я зарабатываю этим на жизнь, и, может быть, вы захотите нанять нас (http://codeintegritysolutions.com/);Сегодня я выступаю с докладом на эту тему в Стэнфорде.Нанять консультанта для настройки имеет большой смысл;поручить сортировку кому-то за пределами компании гораздо сложнее.Поручить исправление постороннему человеку еще сложнее;учиться на своих ошибках даже важнее, чем исправлять их.

  • Я немного расширил эту тему, приведя некоторые фрагменты моего выступления в Стэнфорде для нашего корпоративного блога: http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html.

Answer 2

Один день в неделю:Включите анализ;выберите 100 самых раздражающих предупреждений;исправить их;отключить анализ.Суммируя:не паникуйте;ваш код работает так, как есть (не так ли?);просматривайте предупреждения небольшими порциями.

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

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

Answer 3

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

Answer 4

В качестве подрядчика вы можете пойти более умеренным путем и попросить его исправить только те проблемы, которые очевидны, локальны и не требуют полного понимания вашего кода.Я предполагаю, что большое количество попаданий Coverity — это такие вещи, как возможные разыменования NULL-указателя или возможные записи за конец буфера, которые можно исправить с помощью простых проверок, которые полностью локальны для рассматриваемого кода и не требуют понимания Большая фотография.

Признаюсь, я проделывал подобную работу до использования preFAST/preFIX или того, как называется этот инструмент от Microsoft, и многие из них были механическими изменениями.Хорошо подходит подрядчику или, может быть, даже стажеру.Но будут вещи, которые требуют дополнительного анализа — просто убедитесь, что подрядчику(ам) ясно, что им не следует пытаться углубляться в вещи.

И будьте с ними вежливы — это тяжелая работа, поэтому делайте все, что можете, приятным.

Answer 5

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

Answer 6

Попробуйте другие статические анализаторы.Раньше я работал с Parasoft C++ Test, и у него был удобный способ фильтровать предупреждения по степени их серьезности.

Answer 7

Означает ли это, что у вас есть проблемы с настройкой его под свои нужды?
Как

""Настраиваемый анализ

Статический анализ Coverity предоставляет возможность точной настройки анализа, изменяя либо количество развернутых средств проверки, либо параметры, специфичные для отдельного средства проверки, например пороговое значение для разыменования нулевого указателя.Возможность настройки Coverity для конкретного блока кода или приложения позволяет разработчикам выбирать уровень производительности, наиболее подходящий для их приложения, и приводит к более точным и надежным результатам.Комплект разработки программного обеспечения Coverity позволяет обнаруживать уникальные типы дефектов в коде C и C++ путем создания собственных средств проверки.Это в дополнение к созданию специальных средств проверки для обнаружения параллелизма, обработки исключений и других критических проблем».
http://www.coverity.com/products/static-anaанализ.html

Answer 8

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

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

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