Статический анализ кода - какие из них включить в первую очередь?

Question

Мы используем VS2008 со встроенным набором правил статического анализа кода.
У нас есть относительно большое решение на C # (более 150 проектов), и хотя некоторые из проектов (& Lt; 20) религиозно используют статический анализ кода, большинство - нет. Мы хотим начать применять статический анализ кода ко всем проектам, но включение всех правил приведет к серьезному отвлечению наших текущих проектов. Какое из многих доступных правил статического анализа кода следует включить в первую очередь? Какие правила имеют наибольшую отдачу? Если бы вы могли дать мне свой топ-20, я был бы очень признателен.
Спасибо заранее,
--Ed.S.

Answer 1

Самые первые правила, которые вы должны активировать для проекта, - это те, в отношении которых у вас еще нет нарушений в этом проекте. Это позволит вам избежать появления новых проблем без дополнительных затрат на очистку.

В остальном, учитывая, что вы уже используете анализ кода в других проектах, ваш лучший вклад, для которого правила, скорее всего, будут нарушены с серьезными последствиями, это, вероятно, разработчики, которые работают над этими проектами. Если вам не хватает совпадений между проектами, чтобы получить значимые отзывы от разработчиков, вы можете рассмотреть возможность начать с правил, включенных в набор минимальных рекомендуемых правил Microsoft в Visual Studio 2010.

Если вы планируете фактически устранить существующие нарушения в каком-либо конкретном проекте, вы можете рассмотреть возможность использования FxCop вместо VS Code Analysis до завершения очистки. Это позволит вам немедленно активировать правила, сохраняя при этом & Quot; для очистки & Quot; исключения существующих нарушений за пределами вашего исходного кода.

Answer 2

Учитывая, что Studio похожи на правила FxCop, я могу сказать, какие из них я бы включил последний .

Если интернационализация не на горизонте, отключите правила глобализации.

Сначала отключите правила производительности. Оптимизируйте, когда вам нужно.

Подгоните остальных к вашей команде и вашим проектам. Отключите отдельные правила, которые не применяются. В частности, правила именования могут нуждаться в корректировке.

РЕДАКТИРОВАТЬ: самое главное, чтобы уменьшить шум. Если в каждом проекте будет 200 предупреждений и они останутся такими в течение нескольких месяцев, все будут их игнорировать. Включите правила, которые важны для вашей команды, очистите код, чтобы получить 100% прохождение (или исключите исключения - и будут исключения; это рекомендации), а затем обеспечьте поддержание чистоты кода.

Answer 3

Если вы собираетесь локализовать свой проект / он будет использоваться в разных странах, обязательно включите правила локализации. Он найдет все вызовы для всех видов функций Format / Parse, которые не определяют CultureInfo. Ошибки, связанные с не указанным CultureInfo, трудно найти в тестировании, но они действительно укусят вас в задницу, когда ваш французский клиент спросит: почему ваша программа не работает / вылетает на числах с & Quot;, & Quot ; в качестве десятичного разделителя.

Answer 4

В моем опыте анализа кода предупреждения всех типов показывают «скрытые» ошибки или недостатки в вашем коде. Исправление этих проблем может решить некоторые реальные проблемы. Я не нашел список предупреждений, которые я хотел бы отключить.

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

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

Answer 5

Я несколько согласен с ответом Йеруна Хуининка .

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

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