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

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

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

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

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

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

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


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

>
>
Почему статический анализ кода необходи…

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

12 Апр 2011

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

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

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

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

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

Если проверка всех файлов выполняется очень долго (что характерно для больших проектов), то в PVS-Studio возможно настроить проверку только некоторых файлов. Здесь описано как это можно сделать. Если коротко, то можно либо проверять файлы, модифицированные за последний день (или несколько дней), а можно проверять только указанные в списке файлы (сам список – это файл, заданный в командной строке). В этом случае вы получите, во-первых, каждое утро список новых обнаруженных проблем в коде, а, во-вторых, на это потребуется совсем мало времени. Настройка "Check only Files Modified In (проверять файлы за последний день) может быть полезна и при ручном запуске PVS-Studio в процессе написания кода. Например, закончив правку большого фрагмента программы и добившись, что код компилируется, можно запустить PVS-Studio. Анализатор быстро проверит только те файлы, которые правились сегодня.

Популярные статьи по теме
Анализ потока данных PVS-Studio распутывает всё больше связанных переменных

Дата: 08 Авг 2022

Автор: Артём Ровенский

Это вторая статья про связанные переменные и их поддержку в PVS-Studio. В этот раз мы расскажем об улучшении созданного механизма, разберём примеры из реальных проектов и увидим, какие проблемы польз…
Хочу использовать в своей команде PVS-Studio. Начальник против. Как его убедить?

Дата: 02 Авг 2022

Автор: Сергей Васильев

Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно рабо…
Межмодульный анализ C и C++ проектов в деталях. Часть 2

Дата: 14 Июл 2022

Автор: Олег Лысый

В первой части статьи мы рассматривали основы теории компиляции C и C++ проектов, в частности особое внимание уделили алгоритмам компоновки и оптимизациям. Во второй части мы погрузимся глубже и пока…
Межмодульный анализ C и C++ проектов в деталях. Часть 1

Дата: 08 Июл 2022

Автор: Олег Лысый

Начиная с PVS-Studio 7.14, для C и C++ анализатора появилась поддержка межмодульного анализа. В этой статье, которая будет состоять из двух частей, мы расскажем, как устроены похожие механизмы в комп…
Эволюция PVS-Studio: анализ потока данных для связанных переменных

Дата: 28 Апр 2022

Автор: Никита Липилин

Связанные переменные – одна из главных проблем статического анализа. Данная статья посвящена разбору этой темы и рассказу о том, как разработчики PVS-Studio сражаются с ложными срабатываниями, появив…

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

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно. Хотите узнать подробнее?
Принять