Слишком много ложных срабатываний при использовании FxCop

Question

Мы используем FxCop, и он генерирует слишком много ложных срабатываний по нашему вкусу. Например, если частный метод вызывается с использованием отражения, то этот метод считается потенциально неиспользуемым - понятным, и мы подавляем это предупреждение явно, используя атрибут SuppressMessage. Однако FxCop сообщает об этом же предупреждении для методов, вызванных этим методом, о которых мы уже подавили предупреждения. Это глупо и создает слишком много шума.

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

В любом случае, мне интересно, знает ли кто-нибудь, собирается ли Microsoft обновить FxCop, потому что он, похоже, застрял в версии 1.36 надолго.

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

Может быть, кто-нибудь может предложить хорошую альтернативу FxCop?

Мы используем VS2008 pro.

Спасибо.

Answer 1

Посмотрите на Жандарм , это очень похоже на fxCop, но из проекта Mono.

Жандарм - это расширяемый инструмент на основе правил для поиска проблем в приложениях и библиотеках .NET. Жандарм проверяет программы и библиотеки, содержащие код в формате ECMA CIL (Mono и .NET), и ищет общие проблемы с кодом, проблемы, которые компилятор обычно не проверяет или не проверял исторически. - http://www.mono -project.com / Gendarme

Answer 2

Альтернативой 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 3

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

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

Answer 4

Visual Studio теперь поставляется с анализом кода - встроенный FXCop:

Microsoft Visual Studio 2005 и Visual Studio 2008 Team System Выпуски для разработчиков оба включают «Анализ кода», который основан на FxCop.

Вы можете написать пользовательских правил в FXCop, если он не выполняет то, что вы хотите.