Возможно, вам придется столкнуться с большим количеством ложных срабатываний, особенно если ваша кодовая база велика.
Большинство инструментов статического анализа работают с использованием "внутрипроцедурного анализа", что означает, что они рассматривают каждую процедуру изолированно, в отличие от "анализа всей программы", который рассматривает всю программу.
Как правило, они используют «внутрипроцедурный» анализ, потому что «анализ всей программы» должен учитывать множество путей через программу, которые фактически никогда не будут реализованы на практике, и, следовательно, часто могут давать ложноположительные результаты.
Внутрипроцедурный анализ устраняет эти проблемы, просто сосредоточившись на одной процедуре. Однако для работы им обычно необходимо ввести «язык аннотаций», который вы используете для описания метаданных для аргументов процедуры, типов возвращаемых данных и полей объекта. Для C ++ эти вещи обычно реализуются с помощью макросов, которыми вы украшаете вещи. Затем аннотации описывают такие вещи, как «это поле никогда не является пустым», «этот строковый буфер защищен этим целочисленным значением», «это поле может быть доступно только для потока с пометкой« фон »и т. Д.
Затем инструмент анализа возьмет предоставленные вами аннотации и проверит, что написанный вами код действительно соответствует аннотациям. Например, если вы потенциально можете передать значение null чему-либо, помеченному как отличное от null, это помечает ошибку.
При отсутствии аннотаций инструмент должен предполагать наихудшее и поэтому будет сообщать о множестве ошибок, которые на самом деле не являются ошибками.
Поскольку кажется, что вы еще не используете такой инструмент, вам следует предположить, что вам придется потратить значительное количество времени, комментируя ваш код, чтобы избавиться от всех ложных срабатываний, о которых первоначально будет сообщено. Сначала я запустил бы инструмент и посчитал бы количество ошибок. Это должно дать вам оценку того, сколько времени вам понадобится, чтобы применить его в своей кодовой базе.
Независимо от того, стоит ли инструмент, зависит от вашей организации. Какие ошибки вам больше всего нравятся? Это ошибки переполнения буфера? Это ошибки с нулевым разыменованием или утечкой памяти? У них проблемы с потоками? Являются ли они «ой, мы не учли этот сценарий» или «мы не тестировали китайскую версию нашего продукта, работающую на литовской версии Windows 98?».
Как только вы выясните, в чем заключаются проблемы, вы должны знать, стоит ли это усилий.
Инструмент, вероятно, поможет с ошибками переполнения буфера, нулевого разыменования и утечки памяти. Существует вероятность того, что он может помочь с ошибками потоков, если у него есть поддержка анализа «окрашивания потоков», «эффектов» или «разрешений». Тем не менее, эти виды анализа являются довольно передовыми и имеют ОГРОМНУЮ нотацию, поэтому они сопряжены с определенными затратами. Инструмент, вероятно, не поможет с ошибками любого другого типа.
Итак, это действительно зависит от того, какое программное обеспечение вы пишете, и с какими ошибками вы сталкиваетесь чаще всего.