Как стать автором
Обновить

Как перешагнуть через legacy и начать использовать статический анализ кода

Время на прочтение 8 мин
Количество просмотров 7.5K
Всего голосов 27: ↑21 и ↓6 +15
Комментарии 17

Комментарии 17

А как дела с legacy-кодом в самом PVS-Studio?
По определению — как у всех. Хотя с тестами и стат. анализаторами всё достаточно хорошо, т.к. это всё очень давно используется.

А вот если применить что-нибудь из VS 2017 для Code Style, то без чего-нибудь подобного, о чём речь в статье, на нашем коде тоже невозможно пользоваться.
Два коротких вопроса:
  1. Swift?
  2. MacOS X?
Короткий ответ

Спасибо! Будем посмотреть.
НЛО прилетело и опубликовало эту надпись здесь
попробую купить

Это дело хорошее. Ждем Вас в почте.

Добавить возможность подключать custom plugins к вашей системе, вообще бы было клёво

А вот здесь мы всегда были принципиально против и не планируем создавать такую систему. Кажется, что разрабатывать диагностики просто. Но на самом деле, сделать качественную диагностику очень, очень сложно и дорого (трудозатратно). Во-первых, это сложно просто практически. Например, создавая диагностику, мы смотрим как она работает, проверяя более 100 открытых проектов. Это итерационный процесс продолжается, пока мы не добьёмся приемлемых результатов качества. Во-вторых, при создании новых диагностик нам часто приходится добавлять новые интерфейсы в ядро для сбора нужных данных. Невозможно сделать набор интерфейсов и структур данных на все случаи жизни, тем более, что язык Си++ сейчас быстро развивается и появляются новые конструкции. Поэтому не получится сделать какой-то законченный интерфейс. Все равно пользователям будет нахватать то одного, то другого.

Итого. Сторонние программисты будут тратить много времени и сил (а это дорого), на реализацию собственных диагностик. Плюс будут постоянно отвлекать нас.

Поэтому всем намного проще, быстрее и дешевле, будет если мы просто реализуем на заказ особую диагностику. И мы временами это делаем (см. диагностики с номером V20xx).

Хочу еще раз выделить, что такой подход правильный. Незачем делать что-то самим, если можно использовать специалистов. Нет смысла заставлять программистов мыть полы офисе. Это лучше, быстрее и дешевле, сделает специальный человек (уборщица).
НЛО прилетело и опубликовало эту надпись здесь
Если бы еще добавить возможность подключать custom plugins к вашей системе, вообще бы было клёво.

Вам нужен clang-analyzer: https://clang-analyzer.llvm.org/checker_dev_manual.html

Два вопроса: планируется ли интеграция с SharpDevelop и как запустить режим Standalone с этой средой, если это возможно вообще (у меня не взлетело)?
Для проверки любого нестандартного C/C++ проекта всегда поможет утилита Standalone. Но в случае с C# она может выступать только просмотрщиком/редактором отчётов, полученных в Visual Studio. Интеграция с SharpDevelop сейчас не в приоритете.
Т.к. SharpDevelop использует MSBuild в качестве сборочной системы (поправьте, если не прав), Вы можете попробовать проверить .sln или .csproj с помощью PVS-Studio_Cmd.exe. А для просмотра отчёта уже использовать, например, Standalone.

Я попробовал на синтетическом проекте — получилось.
Отличная идея. Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
быстро глянуть и не ходить на один и тот-же дефект, по несколько раз
Вроде как вся статья о том, как избежать такого)

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

НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий