Для получения триального ключа
заполните форму ниже
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: анализ потока данных для связанных переменных

Дата: 28 Апр 2022

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

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

Дата: 19 Апр 2022

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

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

Дата: 11 Янв 2022

Автор: Андрей Карпов, Павел Еремеев

PVS-Studio предоставляет статические анализаторы для языков C, C++, C# и Java на платформах Windows, Linux и macOS. Несмотря на некоторые различия, накладываемые особенностями отдельных языков, в цел…
Ускоряем сборку и анализ при помощи Incredibuild

Дата: 17 Май 2021

Автор: Максим Звягинцев

"Да сколько ты ещё будешь собирать?" – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распар…
GTK: как выглядит первый запуск анализатора в цифрах

Дата: 04 Янв 2021

Автор: Святослав Размыслов

Внедрение статического анализатора в проект для некоторых людей выглядит непреодолимой преградой. Почему-то очень распространено мнение, что объём выданных результатов анализа при первом запуске наст…

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

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