Какие правила "должны следовать" FxCop для любого разработчика С#?

Ответ 1

В нашем наиболее важном коде:

• Лечить предупреждения как ошибки (уровень 4)
• FxCop должен пройти 100% (вообще не допускается игнорировать)
• Gendarme используется в качестве ориентира (иногда он конфликтует с FxCop)

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

Ответ 2

По-моему, сделайте следующее:

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

• Глобализация
• Interoperability
• Безопасность
• Производительность
• Портативность

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

• Дизайн
• Использование

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

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

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

Ответ 3

Некоторые правила избегают ошибок или утечек:

• Не используйте общие типы исключений (для нас это может быть лучшим правилом. В соответствии с этим, это может быть легко или сложно обеспечить)
• Тест для NaN правильно (легко обеспечить соблюдение)
• Одноразовые поля должны быть удалены (довольно легко обеспечить соблюдение)
• Dispose должен вызвать базовую утилиту (довольно легко обеспечить соблюдение)
• Одноразовые типы должны объявлять финализатор (довольно легко обеспечить соблюдение)

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

• Свойства коллекции должны быть только для чтения (в нашем случае это сложно выполнить)
• Не раскрывайте общий список
• член не должен выставлять определенные типы коннекторов
• Просмотрите устаревшие параметры (улучшает ваш API)

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

Ответ 4

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

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

NDepend перекрывается с FxCop по некоторым правилам кода, но предлагает множество уникальных правил кода. Вот несколько правил, которые я бы классифицировал как обязательные:

• Избегайте уменьшения охвата кода тестированием типов
• Избегайте сложностей сложных методов (Source CC)
• Избегайте преобразования неизменяемого типа в изменчивый
• Переопределения метода() должны вызвать base.Method()
• Избегайте шаблона Singleton
• Типы с одноразовыми полями экземпляра должны быть одноразовыми
• Одноразовые типы с неуправляемыми ресурсами должны объявлять финализатор
• Избегать взаимозависимости пространств имен
• Избегать циклов зависимостей пространств имен
• Уровень пользовательского интерфейса не должен использовать непосредственно типы БД
• API Breaking Changes: Методы
• Комплексные методы, частично покрываемые тестами, должны быть покрыты 100%
• Потенциально мертвые типы
• Структуры должны быть неизменными
• Избегайте имен типов и пространств имен с тем же идентификатором

Обратите внимание, что Правила могут быть проверены жить в Visual Studio и в процессе сборки, сгенерированный отчет HTML + javascript.

Ответ 5

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

Ответ 6

Минимальный fxcop, а также анализ кода (при использовании VS2010 Premium или Ultimate): http://msdn.microsoft.com/en-us/library/dd264893.aspx

Ответ 7

Мы являемся веб-магазином, поэтому оставляем следующие правила:

• Anything with Interop (мы не поддерживаем интеграцию COM, если клиент не платит за него!)
• Подписание ключей (веб-приложениям не нужны высоконадежные прилады)

Иногда мы отказываемся от правила использования более высоких фреймворков в зависимостях, поскольку некоторые из наших CMS все еще являются .NET 2.0, но это не значит, что DAL/Business Layers не могут быть .NET 3.5, не пытаюсь вернуть IQueryable (или что-нибудь .NET 3, 3.5).

Ответ 8

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

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

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

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

Ответ 9

Правила создания и безопасности - это хорошее место для начала.

Ответ 10

Я полностью согласен со Sklivvz. Но для существующих проектов вы можете удалить категории нарушений FxCop по категориям.

Время от времени жандарм принимает новые правила, которые весьма полезны. Поэтому вы можете использовать жандарм.