При анализе достаточно крупных проектов статические анализаторы кода обычно генерируют очень большое количество сообщений об ошибках или предупреждений. И ответ на вопрос, стоит ли исправлять ошибки, и если стоит – то какие, существенно зависит от текущего этапа жизненного цикла проекта.
Если проект находится на этапе создания, то исправление ошибок может быть очень полезным – отделы обеспечения качества еще не потратили время на их нахождение. А сэкономленное время – это сэкономленные деньги.
Когда проект находится в предрелизном состоянии, то к исправлению ошибок нужно относится с большей осторожностью – обязательно исправлять стоит только ошибки высокой степени критичности (по категоризации вашей организации), либо ошибки, которые можно связать с реальными проблемами, выявленными на этапе тестирования и еще не исправленными.
Если проект перешел в состояние поддержки то основная цель – это не внести новых элементов нестабильности в систему. В этом случае полезность системы статического анализа кода проявляется по другому – в начале имеет смысл пометить все ошибки к игнорированию, и, пользуясь регулярными проверками кода, не допускать появления новых. Это позволит увеличить качество всего нового кода. Ну а старые ошибки стоит исправлять по мере рефакторинга тех или иных подсистем – к счастью, благодаря простой системе скрытия ошибок их наличие можно сразу же видеть в исходном коде.
Вторым аспектом проблемы является то, что любой статический анализатор кода всегда выдает, помимо полезных сообщений, еще множество так называемых "ложно-позитивных срабатываний".
Различные статические анализаторы по-разному подходят к данной проблеме. Часть анализаторов игнорирует те подозрительные места в коде, где вероятность наличия ошибки далека от 100%. Но в большинстве статических анализаторов используют противоположный подход, то есть анализатор генерирует гораздо большее количество "ложных" срабатываний, однако и риск потери реальных проблемных сообщений об ошибках значительно меньше.
Поскольку результаты анализа зачастую содержат большое количество таких "ложно-позитивных" сообщений, то исправлять код во всех отмеченных анализатором местах не имеет смысла. Разработчикам однако всё равно следует просматривать все полученные предупреждения и настраивать анализатор под каждый конкретный проект, отсеивая такие низкоприоритетные сообщения и концентрируясь на выявлении наиболее значимых проблем.