Как работать с отчетами по FxCop

Question

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

Список проблем был настолько огромен, что потребовались бы дни, чтобы найти и исправить некоторые, если не все, вещи.

Теперь я знаю, что не очень практично исправлять все, что FxCop говорит вам исправить. Но так как я новичок в этом маленьком инструменте ...

Какие полезные советы и рекомендации по эффективному использованию FxCop?

На новый проект и на существующий проект?

Если также при условии, что программисты в моей компании обычно пишут хороший код?

Answer 1

Сначала вы можете начать с небольшого набора правил в начале. А затем увеличьте количество правил, которые вы применяете.

А также вы должны взглянуть на этого вопроса n ответов ...

Answer 2

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

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

Я почти уверен, что провел целую неделю, исключая / включая нарушения, пока у нас не было списка, подходящего для нашей политики. Потом еще 2-3 просто исправления нарушений. : - (

Answer 3

Создайте базовый уровень, запустив fxCop один раз и исключив все, что он найдет.

Сохраните это как файл .fxcop и используйте его для запуска будущих проверок.

Затем, когда вы вносите изменения в свой код, вы создаете новые управляемые нарушения. FxCop будет пометить вещи, если вы измените сигнатуру метода, например.

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

Answer 4

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

Таким образом, если вы назовете все свои формы такими, как frmMain, FxCop будет жаловаться, потому что это выглядит ужасно в библиотеке классов. Но если вы просто работаете над собственным приложением WinForms, вам все равно. Точно так же вы сходите с ума от всего, что связано с IFormatProvider, перегрузок MessageBox, которые указывают направление текста, и так далее. Но если вы не создаете код для глобальной аудитории, вы можете игнорировать его.

Важно понимать целевую аудиторию FxCop. Вы можете игнорировать некоторые рекомендации в зависимости от того, чем вы отличаетесь от этой аудитории.

Answer 5

Не все, что в отчетах fxCop - это проблемы "mustfix". Например, вставка пользовательского ввода в команду базы данных с использованием конкатенации строк намного хуже, чем проблемы стиля, такие как венгерский или перехват исключений, а не более конкретное исключение.

Answer 6

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

Answer 7

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