У нас есть 3-летнее решение (.sln) с примерно 20 проектами (.csproj). Разумно начать использовать FxCop и/или StyleCop? Может быть, мы должны сначала использовать его для нескольких небольших проектов, но не для всего решения?
Было бы неплохо увидеть некоторые опытные ответы.
Спасибо.
EDIT: Мы используем TeamCity для непрерывной интеграции. И у нас нет возможности использовать ReSharper.:( Только CodeRushXpress.
Да, вы должны, но медленно.
Получите копию ReSharper, установите StyleCop и получите плагин StyleCop для ReSharper, настройте правила, которые вы хотите использовать, и с этого момента на каждом открываемом вами файле будет полно синих синих линий, чтобы рассказать вам, где вещи являются плохими.
Если вы просто исправите их, по одному файлу за раз, вы, в конечном итоге, получите хороший чистый проект, без необходимости убеждать своего босса позволить вам тратить 3 недели на ваш проект, ничего не делая, время!
Получение чистого кода похоже на рефакторинг, если вы попытаетесь сделать это по всему проекту сразу, вы попадете в рассол:)
Альтернативой или хорошим дополнением к FxCop/StyleCop будет использование коммерческого инструмента NDepend. С помощью этого инструмента можно написать правило кода над запросами LINQ (а именно CQLinq). Отказ от ответственности: я являюсь одним из разработчиков этого инструмента
По умолчанию предлагаются более 200 правил кода, включая дизайн, архитектуру, качество кода, эволюцию кода, соглашения об именах, код ошибки, Использование .NET Fx...
CQLinq предназначен для написания правил кода, которые могут быть проверены в прямом эфире в Visual Studio или могут быть проверяется во время процесса сборки и сообщается в отчете HTML/javascript.
Сила CQLinq над FxCop или StyleCop заключается в том, что просто написать правило кода и получить немедленные результаты. Предлагаются средства для просмотра согласованных элементов кода. Конкретно это выглядит так:
Я только что начал использовать StyleCop для своих личных проектов, и для работы через поднятые проблемы требуется немного времени.
Я бы рекомендовал запустить StyleCop по образцу ваших файлов и проанализировать результаты перед запуском, чтобы внести какие-либо изменения.
Например, по умолчанию StyleCop жалуется на отсутствие документации по методу для всех методов, как государственных, так и частных. Теперь я не могу ответить на это за вас, но вам нужно решить, хотите ли вы, чтобы частные методы имели полную документацию или нет (есть аргументы в обоих направлениях). Но вам нужно решить так или иначе. Вы не хотите, чтобы 6 месяцев вносили изменения в одну сторону, а затем решили, что вы хотите, чтобы это было другим. Это либо приведет вас к ненужным изменениям, либо придется пересмотреть код, который, как вы считали, вы закончили.
После того, как вы внесете необходимые настройки в настройки StyleCop, а затем отпустите его на базе кода - по одному проекту за раз.
Что касается FxCop, да, рекомендуется использовать этот инструмент, будь то новый проект или существующий. Как и StyleCop, вы можете запустить инструмент и просмотреть результат. В отличие от StyleCop, FxCop работает с компилированным кодом, а не с исходным кодом.
Это, вероятно, будет сначала подавляющим. Хорошая идея - отключить все группы правил и повторно запустить инструмент, чтобы получить чистый список. Включать одну группу за раз, разрешать любые сообщения, которые появляются, или отключать определенные правила в этой группе, если они не применяются к вам (правила по умолчанию в целом довольно широкие, и не все будут применяться; вам нужно настроить набор правил для ваших нужд).
В конце вы разрешите все сообщения, выполнив соответствующие исправления или выборочно отключив посторонние правила.
Как правило (без каламбура) Я считаю, что для групп безопасности и производительности нужны хорошие. Правила именования являются субъективными и могут противоречить вашим собственным соглашениям. Если это так, выключите их. Мобильность и глобализация также субъективны и зависят от ваших потребностей. Что же касается остальных, то вы сами делаете свои выводы!
В зависимости от того, как было создано решение, интеграция (и устранение проблем, данных этими инструментами) может занять много времени, поэтому я думаю, что интеграция проектов один за другим - это то, как вы должны идти.
ИЗМЕНИТЬ
В дополнение к ответу Ed Woodcock: вы можете настроить SyleCop (и я тоже ставлю FxCop), чтобы автоматически запускать свои проверки во время каждой сборки VS. Используя эту функцию, вы можете поочередно проверять все свои проекты и исправлять все предупреждения (также вы можете настроить эти инструменты для генерации ошибок) только во время вашей обычной разработки.
Это зависит:
Я думаю, что это сводится к возможному сокращению стоимости для поддержания вашей текущей базы кода по сравнению с стоимостью получения базы кода для прохождения инструменты проверки. Более последовательная база кода будет иметь меньшую стоимость обслуживания, но это значение имеет значение , если вы делаете много изменений в базе кода.