Comments 5
у нас есть несколько хитростей
И не только у вас: www.mono-project.com/Gendarme — правила разделены на группы, есть отдельно регулируемые уровни severity и verbosity.
В-третьих, мы постоянно боремся с ложными срабатываниями.
Задумка хорошая, но очень опасная — если вы мне исключили 100 ложных срабатываний и при этом подавили 1 эффективное сообщение, то я вам за это спасибо бы не сказал! Предоставте пользователю возомжность подавалять сообщения (файл, строка, код сообщения) и этого будет достаточно. Одно-два сообщения на проект не составят труда для него, а если их сотни и тысячи, то тут проблема в другом…
Как вы считаете, нужны ли конечному пользователю анализатора кода предоставленные в статье графики в виде end-user инструмента?
PVS-Studio не пользовался, пользовался cppcheck — необходимости в подобных графиках не испытываю, но возможно это было бы интересно (не более).
Предоставте пользователю возомжность подавалять сообщения (файл, строка, код сообщения) и этого будет достаточно.
Это все конечно же есть. Но опыт показывает, что и проблема, описанная в статье реальна.
пользовался cppcheck
Расскажите, пожалуйста, про свой опыт? Вы его регулярно применяли или разок запустили? Как он Вам по удобству работы?
Но опыт показывает, что и проблема, описанная в статье реальна.Вам виднее…
Расскажите, пожалуйста, про свой опыт?Применяю регулярно — анализ кода «прикручен» к серверу непрерывной интеграции. В целом инструмент приемлемый, но есть несколько нюансов:
— вручную нужно прописывать пути к include'ам (а с развитием проекта они могут меняться).
— существует договоренность о стиле, которая иногда мешает если include приписал в треугольных скобках, то cppcheck производить анализ тех файлов не будет, а если в кавычках — то будет (причем невзирая на опцию игнорирования).
Сообщения об ошибках (именно об error) все эффективные, предупреждения (warning) не особо, иногда очень интересные сообщения попадают в секцию style, советы по производительности, на мой взгляд, тривиальны — это очень бегло.
Задумка хорошая, но очень опасная — если вы мне исключили 100 ложных срабатываний и при этом подавили 1 эффективное сообщение, то я вам за это спасибо бы не сказал!
Не согласен. То есть я конечно понимаю, что потерять ошибку это плохо. Но ещё хуже потерять множество ошибок в огромном отчете. В одной статье компании Parasoft есть список типичных ошибок, которые допускают программисты при работе с инструментами статического анализа. Там есть хорошая мысль по данной тематике. Напишу её своими словами.
Программисты постоянно тяготеют к тому, чтобы включить предупреждения на максимум, будучи уверенны, что так лучше. И получают взрыв из сообщений. В результате теряются полезное среди бесполезного. Внимательно просмотреть много сообщений невозможно. Легко вообще пометить ошибку как ложное срабатывание и забыть про это место. Анализ большого лога отнимает много времени и люди «ускоряются». В результате толку намного меньше, чем могло было быть.
Sign up to leave a comment.
Что общего у статического анализа и поисковиков? Хороший «top»!