В компании, в которой я работал, в двух миллионах строк кода (кашляющих) мы расширили количество предупреждений примерно до 16 000, прежде чем решили совместными усилиями сократить их до 0. Это было очень приятно достичьчто через месяц или около того.
Мы сохранили статистику о том, сколько найденных нами ошибок было на самом деле помечено предупреждениями.Некоторые были субъективными, многие были второстепенными, и у меня нет точного числа под рукой, когда я перешел.Однако в одном модуле с ~ 1050 предупреждениями было около 100 проблем, определенных как ошибки, «влияющие на обслуживание».Хотя это был основной модуль.
- edit-- - эта статья о программном обеспечении Defect Free - интересное прочтение по этому вопросу.
Тогда о на этой странице :
В этой статье автор приводит цифры из "большого объема эмпирических исследований", опубликованные в Оценки программного обеспечения, сравнительные тесты и лучшие практики(Джонс, 2000) .На уровне 1 SIE CMM, который звучит как уровень этого кода, можно ожидать частоту дефектов 0,75 на функциональную точку.Я оставлю вам решать, как функциональные точки и LOC могут быть связаны в вашем коде - вам, вероятно, понадобится инструмент метрик для выполнения этого анализа.
Стив Макконнелл в Code Complete цитирует исследование из 11 проектов, разработанных одной командой, 5 без проверки кода, 6 с проверкой кода.Уровень дефектности для не проверенного кода составлял 4,5 на 100 LOC, а для проверенного - 0,82.Таким образом, на этом основании ваша оценка кажется справедливой в отсутствие какой-либо другой информации.Однако я должен предположить уровень профессионализма среди этой команды (только из-за того, что они чувствовали необходимость в проведении исследования), и что они хотя бы следили за предупреждениями;Ваш уровень дефектов может быть намного выше.
Пожалуй, самый ценный урок, который вы можете извлечь - относитесь ко всем предупреждениям как к ошибкам, пока не доказано обратное, и даже тогда исправьте их.