Как реализовать FxCop / статический анализ на базе существующего кода

Question

Какие стратегии используются при реализации FxCop / статического анализа на существующих кодах с существующими нарушениями? Как наиболее эффективно уменьшить нарушения статического анализа?

Answer 1

Начните с либерального использования атрибута [SuppressMessage]. По крайней мере, в начале. Как только вы получите счетчик с помощью атрибута, вы добавите в правило, что новые проверки не могут представлять нарушения FxCop.

Visual Studio 2008 имеет замечательную функцию анализа кода, которая позволяет вам гарантировать, что анализ кода выполняется при каждой сборке, и вы можете рассматривать предупреждения как ошибки. Это может немного замедлить работу, поэтому я рекомендую настроить сервер непрерывной интеграции (например, CruiseControl.NET) и запускать анализ кода при каждой регистрации.

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

Чтобы отслеживать, какие из них вы действительно хотите сохранить, всегда добавляйте значение Justification к тем, которые вы действительно хотите подавить.

Answer 2

Перепишите свой код в стиле прохождения!

Серьезно, в старой кодовой базе будут сотни ошибок, но именно поэтому у нас есть начинающие / интерновые программисты. Исправление нарушений FxCop - отличный способ получить представление о базе кода, а также научиться писать соответствующий код .NET.

Так что просто откусите пулю, выпейте много кофеина, и просто пройдите через это пару дней!

Answer 3

Альтернативой FxCop было бы использование инструмента NDepend . Этот инструмент позволяет писать правила кода для запросов C # LINQ (что мы называем CQLinq ). Отказ от ответственности: я один из разработчиков инструмента

По умолчанию предлагается более 200 правил кода . Настроить существующие правила или создать свои собственные правила легко благодаря хорошо известному синтаксису C # LINQ .

Чтобы сохранить количество ложных срабатываний на низком уровне, CQLinq предлагает уникальные возможности для определения набора JustMyCode с помощью специальных запросов кода с префиксом notmycode . Дополнительные объяснения об этой функции можно найти здесь . Вот, например, два notmycode запроса по умолчанию:

• Отказ от сгенерированных и дизайнерских методов из JustMyCode
• Отменить сгенерированные типы из JustMyCode

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

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Наконец, обратите внимание, что с помощью кода NDepend можно проверить правила жить в Visual Studio и во время процесса сборки в сгенерированном отчете HTML + JavaScript .

Answer 4

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

Есть еще идеи?