Должны ли мы начать использовать FxCop и / или StyleCop в зрелом проекте?

Question

У нас есть 3-летнее решение (.sln) с около 20 проектами (.csproj). Целесообразно начать использовать FxCop и / или StyleCop? Может быть, нам следует сначала использовать его для нескольких небольших проектов, но не для полного решения?

Было бы хорошо увидеть некоторые опытные ответы.

Спасибо.

РЕДАКТИРОВАТЬ: Мы используем TeamCity для непрерывной интеграции. И у нас нет возможности использовать ReSharper. :( Только CodeRushXpress.

Answer 1

Да, надо, но медленно.

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

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

Получение чистого кода похоже на рефакторинг, если вы попытаетесь сделать это сразу для всего проекта, вы попадете в засолку:)

Answer 2

Альтернативой или хорошим дополнением к FxCop / StyleCop будет использование коммерческого инструмента NDepend . С помощью этого инструмента можно написать правило кода поверх запросов LINQ (а именно CQLinq) . Отказ от ответственности: я один из разработчиков инструмента

По умолчанию предлагается более 200 правил кода , к ним относятся дизайн , архитектура , качество кода , код evolution , соглашения об именах , мертвый код , .NET Fx использование ...

CQLinq предназначен для написания правил кода, которые могут быть проверены в реальном времени в Visual Studio или которые могут быть проверены в процессе сборки и представлены в отчете HTML / javascript .

Сила CQLinq по сравнению с FxCop или StyleCop в том, что просто написать правило кода и сразу получить результатов. Предлагаются средства для просмотра соответствующих элементов кода. Конкретно это выглядит так:

1042 * *

Answer 3

Я только что начал использовать StyleCop в своих личных проектах, и мне нужно немного времени, чтобы разобраться с поднятыми "проблемами".

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

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

Как только вы сделаете необходимые изменения в настройках StyleCop, а затем отпустите его на своей кодовой базе - по одному проекту за раз.

Answer 4

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

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

В конце вы разрешите все сообщения, либо применив соответствующие исправления, либо выборочно отключив посторонние правила.

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

Answer 5

Это зависит от:

• Нет смысла в изменении кода, который работает ради него.
• Стиль кодирования StyleCop может не соответствовать стилю вашего текущего кода.
• Вы, вероятно, будете вносить ошибки, если попытаетесь заставить ваш текущий код передать FxCop и / или StyleCop
• Многие правила FxCop не имеют большого значения или не имеют значения, если только третьи лица не пишут код снова для ваших dll.
• Нет смысла использовать инструмент проверки, если вы проигнорируете 101 предупреждение от него, так как вы никогда не найдете важного, который вас волнует.

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

Answer 6

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

EDIT

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