Каковы реальные преимущества статического анализа кода?

Такие инструменты, как pc-lint или QAC, могут использоваться для выполнения статического анализа кода на основе кода.

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

Каковы реальные преимущества статического анализа кода?

Я работал в месте, где использовалась коммерческая система статического анализа кода под названием Coverity Prevent, и это было чертовски здорово! Это действительно сложный и умный.

Мы добавили в него около 18 ГБ как кода с открытым исходным кодом, так и проприетарного кода на C и C ++, и он проследил бы пути кода и быстро нашел бы тонкие ошибки, которые потребовались бы человеку навсегда, чтобы его отследить. Это было также замечательно в определении вещей, которые обычно были бы Heisenbugs.

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

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

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

Начиная с нового языка, приятно иметь тренера. Вот как я думаю об инструментах статического анализа. Я пишу много javascript и вначале у меня появилось несколько вредных привычек, главным образом потому, что я переносил некоторые вещи из более ранних языков. Javascript довольно гибок, так что вы можете делать что угодно, но если бы jslint предупредил меня об определенных шаблонах, я бы с самого начала подобрал лучшие шаблоны кодирования вместо того, чтобы позже переучиваться.

Статические анализаторы - это, в основном, машинные обзоры кода. Они укажут на сомнительные области, которые могут быть упущены во время регулярного тестирования.

Например, действительно ли автор хотел сделать назначение в этом условном выражении?

if (x = 1) {
    ...
}

Или, может быть, новичок смущает лексический кастинг:

char* number = "123";
int converted = number;

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

С точки зрения консультанта, каждый инструмент статического анализа будет иметь некоторый шум, но не все статические анализаторы созданы равными. Инструменты статического анализа, такие как Coverity, Klocwork, Grammatech, имеют хорошие методы анализа, которые должны давать более точные результаты. Если вы настраиваете и настраиваете немного больше, вы обычно получаете лучшие результаты (в конце концов, статические анализаторы должны быть в состоянии работать на всех типах кода от крошечного медицинского устройства до сетевой операционной системы). Определение «шума» также зависит от ваших критериев того, что представляет собой отчет, достойный исправления. С одной стороны, некоторые разработчики отмечают все отчеты, которые они не исправляют, как «ложные» (даже плохо написанный код, который у них нет времени на исправление), а с другой стороны,

Некоторые из этих инструментов более сфокусированы на анализе, а другие - на настольных компьютерах, хотя все три имеют функции, которые поддерживают оба. Как упомянул @Bob, они стоят денег.

В моей предыдущей компании мы использовали статический анализатор Parasoft. И внутри команды считалось, что как минимум 60% ошибок времени выполнения были обнаружены до компиляции.

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

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

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

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

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

Скорее, это хорошая проверка здравомыслия, чтобы проконсультироваться, если у вас есть ошибка и вы не можете ее выяснить . В этом случае вы можете развлечь ложные срабатывания, и, возможно, вы уже сузили возможные источники ошибки. Например, если вы воспроизводите свою ошибку, даже не выполняя какой-либо модуль, вы можете игнорировать то, что FindBugs говорит для них. Это особенно полезно, когда вы смотрите на кусок кода и думаете, что он говорит об одном, тогда как компилятор читает его буквально (например, в Java, когда у вас есть equalsметод, который принимает тип класса вместо Object).

Вы также можете использовать инструменты статического анализа как часть вашего процесса разработки: когда разработчик получает обзор кода, он также должен запускать FindBugs на нем. Короче говоря, это полезно, но вы не будете использовать его так часто, как компилятор или текстовый редактор.