metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Стоит ли исправлять все ошибки, найденн…

Стоит ли исправлять все ошибки, найденные статическим анализатором кода?

05 Апр 2013

При анализе достаточно крупных проектов статические анализаторы кода обычно генерируют очень большое количество сообщений об ошибках или предупреждений. И ответ на вопрос, стоит ли исправлять ошибки, и если стоит – то какие, существенно зависит от текущего этапа жизненного цикла проекта.

Если проект находится на этапе создания, то исправление ошибок может быть очень полезным – отделы обеспечения качества еще не потратили время на их нахождение. А сэкономленное время – это сэкономленные деньги.

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

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

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

Различные статические анализаторы по-разному подходят к данной проблеме. Часть анализаторов игнорирует те подозрительные места в коде, где вероятность наличия ошибки далека от 100%. Но в большинстве статических анализаторов используют противоположный подход, то есть анализатор генерирует гораздо большее количество "ложных" срабатываний, однако и риск потери реальных проблемных сообщений об ошибках значительно меньше.

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

Библиографический список

Популярные статьи по теме


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

Следующие комментарии next comments
close comment form