Какие правила FxCop "должен соблюдать" любой разработчик C#?
Я планирую начать использовать FxCop в одном из наших текущих проектов. Но когда я попробовал выбрать все доступные правила, оказалось, что мне нужно внести много изменений в свой код. Будучи «членом команды», я не могу сразу начать вносить эти изменения, такие как изменение соглашения об именах и т. д., В любом случае я бы хотел начать использовать FxCop с минимальным набором правил и постепенно увеличивал бы набор правил по мере продвижения. Можете ли вы предложить мне несколько обязательных правил FxCop, которым я должен начать следовать. Или вы предлагаете лучший подход?
Примечание. Большая часть моего кода написана на C#.
Ответы 10
Правила дизайна и безопасности - хорошее место для начала.
На мой взгляд, нужно сделать следующее:
Для любого нового проекта соблюдайте все правила FxCop. Вы можете отключить некоторые из них, поскольку не все будет иметь смысл для вашего проекта. Для существующего проекта, как минимум, следуйте правилам из этих категорий:
- Глобализация
- Совместимость
- Безопасность
- Представление
- Портативность
Поскольку это обычно всего несколько нарушений правил в существующем проекте по сравнению с другими категориями, но они могут улучшить качество вашего приложения. Когда эти правила станут ясными, попробуйте исправить следующие категории:
- Дизайн
- использование
Так как это облегчит вам выявление ошибок, связанных с нарушениями, но у вас будет большое количество нарушений в существующем коде.
Всегда сортируйте нарушения по уровню / категории исправлений и начинайте с критических. Пропустите пока предупреждения.
Если вы не знали, от Microsoft также доступен StyleCop, который проверяет ваш код на уровне исходного кода. Обязательно включите интеграцию MSBuild во время установки.
О нашем самом важном коде:
- Считать предупреждения ошибками (уровень 4)
- FxCop должен пройти 100% (игнорирование обычно не допускается)
- Жандарм используется в качестве ориентира (иногда он конфликтует с FxCop)
Вы не поверите, но FxCop чертовски многому научит вас, как писать лучший код ... отличный инструмент! Так что для нас все правила одинаково важны.
@Skliwz: +1, разница только в том, что мы запускаем сокращенный набор во время разработки, но должны передать его полностью для контроля качества.
Многие правила FxCop имеют высокий уровень ложных срабатываний. Например, функции, начинающиеся с «Get», или перехват общих исключений.
Я действительно считаю, что это слишком суровый ответ на вопрос. Включение ВСЕХ правил FxCop для любой зрелой кодовой базы любого приличного размера приведет к тысячам ошибок. Вы должны встроить его в существующую кодовую базу.
+1 за комментарий Марка. Даже собственный код Microsoft не проходит 100% на FxCop. Например, MVC3 повсеместно нарушает правило «URI не должны быть строками». Кроме того, если вы добавляете ссылку на службу из VS и заставляете ее генерировать клиент WCF из WSDL, этот сгенерированный код также не проходит 100%.
Мы интернет-магазин, поэтому мы отказываемся от следующих правил:
- Что угодно с Interop (мы не поддерживаем интеграцию COM, если за это не платит клиент!)
- Подпись ключей (веб-приложениям не нужны высокие требования к безопасности)
Иногда мы откажемся от правила использования более высоких фреймворков в зависимостях, поскольку некоторые из наших CMS все еще являются .NET 2.0, но это не значит, что DAL / Business Layers не могут быть .NET 3.5, пока вы не пытаетесь чтобы вернуть IQueryable (или что-нибудь .NET 3, 3.5).
Полностью согласен со Скливвз. Но для существующих проектов вы можете убирать нарушения FxCop по категориям.
Время от времени жандармы принимают новые правила, которые весьма полезны. Так что, кроме того, вы можете использовать жандарма.
В нашем процессе мы задействовали все правила, а затем мы должны обосновать любые запреты в рамках нашего процесса проверки. Часто просто невозможно исправить ошибку оперативным образом в отношении крайних сроков, или это ошибка, вызванная ошибкой (это иногда происходит, особенно если ваша архитектура обрабатывает плагины через отражение).
Мы также написали настраиваемое правило для глобализации, чтобы заменить существующее, потому что мы не хотели глобализировать строки, передаваемые в исключения.
В общем, я бы сказал, что лучше стараться придерживаться всех правил. В моем текущем домашнем проекте у меня есть четыре конфигурации сборки - один набор, который указывает определение CODE_ANALYSIS, и один набор, который не определяет. Таким образом, я могу видеть все сообщения, которые я подавил, просто создав конфигурацию, отличную от CODE_ANALYSIS. Это означает, что подавленные сообщения могут периодически проверяться и потенциально исправляться или удаляться по мере необходимости.
Что я хотел бы сделать в долгосрочной перспективе, так это сделать этап сборки, который анализирует атрибуты SuppressMessage на предмет фактических ошибок и выделяет те подавления, которые больше не требуются, но в настоящее время это невозможно с моей настройкой.
Альтернативой FxCop было бы использование инструмента NDepend, который позволяет писать Правила кода для запросов C# LINQ (а именно CQLinq). Отказ от ответственности: я один из разработчиков инструмента
По умолчанию предлагается больше 200 кодовых правил. Настройка существующих правил или создание собственных правил просты благодаря синтаксису хорошо известный C# LINQ.
NDepend пересекается с FxCop по некоторым правилам кода, но предлагает множество уникальных правил кода. Вот несколько правил, которые я бы классифицировал как должен следовать:
- Избегайте уменьшения покрытия кода тестами типов
- Избегайте усложнения сложных методов (Source CC)
- Избегайте преобразования неизменяемого типа в изменяемый
- Переопределения Method () должны вызывать base.Method ()
- Избегайте шаблона Singleton
- Типы с одноразовыми полями экземпляров должны быть одноразовыми
- Одноразовые типы с неуправляемыми ресурсами должны объявлять финализатор
- Избегайте взаимозависимых пространств имен
- Избегайте циклов зависимости пространств имен
- Слой пользовательского интерфейса не должен напрямую использовать типы БД
- Критические изменения API: методы
- Сложные методы, частично охваченные тестами, должны быть покрыты на 100%
- Потенциально мертвые типы
- Структуры должны быть неизменными
- Избегайте именования типов и пространств имен с одним и тем же идентификатором
Обратите внимание, что правила можно проверить жить в Visual Studio и во время процесса сборки в сгенерированный отчет HTML + javascript.
Включайте по одному правилу за раз. Исправьте или исключите любые предупреждения, о которых он сообщает, а затем переходите к следующему.
Некоторые правила позволяют избежать ошибок и утечек:
- Не перехватывайте общие типы исключений (это может быть для нас лучшим правилом. В зависимости от конкретного случая может быть легко или сложно обеспечить соблюдение)
- Правильно проверьте NaN (легко обеспечить)
- Одноразовые поля должны быть удалены (довольно легко принудительно)
- Dispose должен вызывать базовое удаление (довольно легко принудительно)
- Одноразовые типы должны объявлять финализатор (довольно легко применить)
Некоторые помогают нам улучшить дизайн, но будьте осторожны, они могут привести к серьезному рефакторингу, когда будет затронут центральный API. Нам нравится
- Свойства коллекции должны быть доступны только для чтения (в нашем случае это сложно обеспечить)
- Не показывать общий список
- член не должен выставлять определенные типы conrete
- Просмотрите используемые параметры (легко улучшает ваш API)
Кто-то в нашем проекте попробовал правила исполнения без каких-либо улучшений. (На самом деле эти правила касаются микрооптимизации, которая не дает результата, если идентификация узких мест не показывает, что микрооптимизация необходима). Я бы посоветовал начать с этих нет.
Это лучший ответ. В частности, вы хотите использовать DataflowRules.dll, в котором есть все одноразовые принадлежности, что является наиболее важным.
Большинство одноразовых типов должны объявлять финализатор в нет; Я бы сказал, что тип обычно должен использовать финализатор только для запуска очистки (а не диагностических предупреждений), если его единственная цель - управлять одним неуправляемым ресурсом, и никакая ссылка на какой-либо экземпляр никогда не будет открыта для любого кода, кроме его владельца. Любые другие объекты, которые инкапсулируют один или несколько неуправляемых ресурсов, должны инкапсулировать каждый такой ресурс в объект, на который он содержит единственную ссылку. Обратите внимание, что такая конструкция защитит финализируемые объекты от внешних вызовов GC.SuppressFinalize.
Минимальный fxcop, а также анализ кода (при использовании VS2010 Premium или Ultimate) следующий: http://msdn.microsoft.com/en-us/library/dd264893.aspx
+1 stylecop, он также прекрасно интегрируется с reSharper. Обязательно соблюдайте стандарты кодирования в своем коде, и если он достаточно хорош и работает должным образом, вы можете в конечном итоге привлечь других людей, но будьте готовы к долгому пути!