Pull to refresh

Comments 5

Шаг первый. Для начала используйте статический анализ хоть как-нибудь. Если вы не использовали статический анализ ранее, то запускайте его хоть раз в месяц. Но запускайте. Ошибка, которую найдёте вы сами, стоит дешевле, чем ошибка, которую найдёт ваш клиент.

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


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

Это если ваш анализатор такое умеет, ну и вдобавок, если просто спрятать гору мусора, какой тогда прок от анализатора?

И… все. Это в целом путь в никуда, потому что кто будет эти ошибки исправлять, вести учет и прочее? Тот же человек, который иногда его запускает?
Не соглашусь, что это в путь в никуда. Да, это совершенно неэффективный подход. Но это уже лучше, чем совсем не использовать статический анализ кода. И не важно, кто будет искать и исправлять ошибки. Главное, что будет сделан первый шаг к освоению методологии статического анализа кода.

Для компромисса, давайте считать, что первый шаг, это знакомство с инструментом. Пусть человеку понравится статический анализ кода, пусть он увидит, что находятся ошибки. Тогда он задумается о необходимости делать это почаще.

Это если ваш анализатор такое умеет,
Умеет. И не только PVS-Studio. Такая возможность есть в любом серьезном анализаторе.

ну и вдобавок, если просто спрятать гору мусора, какой тогда прок от анализатора?
Никто не говорит, что потом нельзя вернуться к изучению скрытых предупреждений. Это предназначено для облегчения этапа внедрения. Можно начать сразу работать с предупреждениями, выдаваемыми для нового кода, а к старым ошибкам вернуться позже. Как показывает практика, эти старые ошибки менее критичны, иначе приложение бы просто не работало. Т.е. серьезные и явные ошибки уже исправлены и остались те, которые проявляет себя редко или не сильно раздражают пользователей. Эти ошибки конечно тоже стоит править, но с ними пользователи мирятся (возможно годами), а значит они могут и ещё подождать :).

P.S. Другие дело, если стоит задача устранения потенциальных уязвимостей. Здесь не важно, проявляет себя ошибка при нормальном режиме работы или нет. С точки зрения пользователя, ошибки вообще нет и все работает правильно. Но при этом ошибка может эксплуатироваться при подсовывании некорректных входных данных и про это даже никто не догадывается. Поэтому, в этом случае есть смысл изучать сразу все предупреждения, как новые, так и старые.
< Если просто спрятать гору мусора, какой тогда прок от анализатора?
Никто не говорит, что потом нельзя вернуться к изучению скрытых предупреждений.

Кстати, да. Это серьезно упрощает жизнь разработчику. В 99% старый код отдебажен, стреляет изредка, выполняет свои задачи. А вот чтобы не наступать на новые грабли и упростить себе жизнь, снизить кол-во часов, проведенных в дебаггере, лучше пользоваться статическим анализатором.

противоречивые шаги вы предлагаете: сначала «важно найти ошибку как можно раньше», а потом «отключайте все сообщения». начинается всё с характеристик качества продукта — что именно хотите проверять анализатором. предложили бы отключать некоторые классы сообщений, которые минорные с точки зрения уязвимостей. ну например, про дублирование кода. а то так можно сообщение про sql injection отключить, а потом и не вспомнить про него.
SQALE-пирамида, например, как раз один из способов приоритезации сообщений анализатора.

Как показывает практика, эти старые ошибки менее критичны, иначе приложение бы просто не работало.

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

Отключать отдельные диагностики можно. Можно исключать определённые папки с каталогами. И так далее. Подробности описаны в документации. Здесь же была сделана дать некое общее видение ситуации.
Sign up to leave a comment.