Исходники plog-converter переехали на Github. Для тех, кто не знает, что такое plog-converter, есть описание утилиты. Она позволяет конвертировать отчеты анализатора в различные форматы.
А у разработчиков, использующих Linux, все тоже нормально. Так как статический анализ также интегрирован в рабочий процесс, по коммитамм запускаются проверки и все работает как надо.
Библиотеки довольно часто используются в исходниках. И да, можно там что-то поправить. Но если обновляется библиотека, то либо надо тянуть свои правки в новую версию, либо пытаться понять, нужны ли они в новой версии. Конечно это довольно сложно и в целом люди забивают на правки исходников чужих библиотек, если это хоть сколько-то возможно сделать.
Например, в PVS-Studio есть технология Mass Suppression. Она позволяет разметить все сообщения, которые выдает анализатор, как «неинтересные». И при следующем прогоне анализа будет выдано 0 сообщений. Далее даже полный прогон анализатора будет выдавать сообщения только на новый или на модифицированный старый код.
Это позволяет внедрить анализатор в проект любого размера и получать пользу от этого на следующий же день. Ни в коем случае не надо править сразу все сообщения, которые выдаст анализатор при первом запуске на реальном большом проекте. Исправление сотен или даже тысяч сообщений почти наверняка приведет к появлению новых проблем.
Их надо править постепенно, планово выделяя на это время.
Вам хочется цифр и конкретики. ОК, я лично участвовал во внедрении анализатора в C++ проект размером 8 млн строк кода. При первом запуске там было порядка 5 000 сообщений от анализатора уровней High и Medium («совсем страшно» и «страшновато»). Сообщения уровня Low («скорее всего не ошибка, но мало ли») игнорировались и не правились. Полный прогон такого проекта в PVS-Studio занимал 6 часов.
Все 5 000 ошибок были сначала подавлены как «неинтересные», и разработчики смогли получать уведомления только о новых ошибках. И сразу их править. На эти оставшиеся 5 000 ошибок была выделена команда 3-5 человек, которая победила их за 3-4 месяца. Цифры немного плавающие, так как кроме этого были все же и другие задачи с разной интенсивностью для этой команды, но в целом порядок оценить можно довольно точно.
Ха! Вот так встреча, очень рад! Константин, давно не виделись. И у нас все ходы записаны. Обалдеть, 2007 год…
From: Konstantin ... [mailto: ... @rim.com]
Sent: Friday, March 2, 2007 6:54 PM
To: Evgeniy Ryzhkov <...@viva64.com>
Subject: RE: Viva64
Уже и RIM нету…
Кстати компания RIM должна была стать вообще нашим первым клиентом. Но не стала (первым), потому что только NDA мы согласовывали и подписывали год. И не потому что мы такие тормозные или требовательные, просто бюрократическая машина RIM не позволяла по какой-то причине просто купить маленькую программку за несколько сотен долларов. К счастью, мы смогли выдержать это все, завершить сделку и даже пережить RIM.
С проектами типа Chromium никакие инструменты из коробки не работают. Это не моя мысль — это говорили ребята из московской разработки Google, пока ее не разогнали.
Это я к чему. Нет смысла самому прикручивать пытаться, надо нам написать и все подскажем. Судя по количеству наших статей про Chromium, все-таки PVS-Studio прикручивается :-).
— Просто используйте его регулярно!
Это то, что мы всем и всегда говорим.
Это позволяет внедрить анализатор в проект любого размера и получать пользу от этого на следующий же день. Ни в коем случае не надо править сразу все сообщения, которые выдаст анализатор при первом запуске на реальном большом проекте. Исправление сотен или даже тысяч сообщений почти наверняка приведет к появлению новых проблем.
Их надо править постепенно, планово выделяя на это время.
Вам хочется цифр и конкретики. ОК, я лично участвовал во внедрении анализатора в C++ проект размером 8 млн строк кода. При первом запуске там было порядка 5 000 сообщений от анализатора уровней High и Medium («совсем страшно» и «страшновато»). Сообщения уровня Low («скорее всего не ошибка, но мало ли») игнорировались и не правились. Полный прогон такого проекта в PVS-Studio занимал 6 часов.
Все 5 000 ошибок были сначала подавлены как «неинтересные», и разработчики смогли получать уведомления только о новых ошибках. И сразу их править. На эти оставшиеся 5 000 ошибок была выделена команда 3-5 человек, которая победила их за 3-4 месяца. Цифры немного плавающие, так как кроме этого были все же и другие задачи с разной интенсивностью для этой команды, но в целом порядок оценить можно довольно точно.
From: Konstantin ... [mailto: ... @rim.com]
Sent: Friday, March 2, 2007 6:54 PM
To: Evgeniy Ryzhkov <...@viva64.com>
Subject: RE: Viva64
Уже и RIM нету…
Кстати компания RIM должна была стать вообще нашим первым клиентом. Но не стала (первым), потому что только NDA мы согласовывали и подписывали год. И не потому что мы такие тормозные или требовательные, просто бюрократическая машина RIM не позволяла по какой-то причине просто купить маленькую программку за несколько сотен долларов. К счастью, мы смогли выдержать это все, завершить сделку и даже пережить RIM.
Времена…
В смысле пока вы эти будете чинить, мы еще опубликуем статью :-).
Ээээ… Константин? RIM?
Это я к чему. Нет смысла самому прикручивать пытаться, надо нам написать и все подскажем. Судя по количеству наших статей про Chromium, все-таки PVS-Studio прикручивается :-).
Отлично работает (на тестах у нас)! В следующем году релизим поддержку embedded-систем.