После ознакомления с Приложением A "Соглашения о стиле кодирования С#" в книге "Руководство по дизайну рамок" (2-е издание от ноября 2008 года) я совершенно смущен тем, что стиль кодирования Microsoft использует внутренне/рекомендую.
Запись в блоге Краткая история стиля С#:
Фактически, различия между стилем StyleCop и "Framework Design Guidelines style" относительно незначительны
Как я вижу, различия довольно выражены. StyleCop говорит, что открывающая фигурная скобка должна быть отдельной строкой, в Руководстве по дизайну рамок указано, что это должно быть после вступительного заявления. StyleCop говорит, что за всеми ключевыми словами следует пробел, в Руководстве по дизайну рамок говорится: "Избавьтесь от всех пробелов" (даже вокруг двоичных операторов).
Я нахожу это правило из руководства по дизайну Framework особенно ироничным (стр. 366, 6-е правило сверху):
Не используйте пробелы перед операциями управления потоком
Right: while(x==y) Wrong: while (x == y)
Это явно указывает, что стиль StyleCop неверен (пробел после ключевого слова while, пробелы до и после двоичного оператора равенства).
В конце код, отформатированный с использованием стиля StyleCop, имеет совсем другое "чувство" от того, которое отформатировано с использованием стиля Framework Design Guidelines. Следуя стилю Framework Design Guidelines, нужно было бы отключить кучу правил (И нет правил, которые проверяют соблюдение стиля Framework Design Guidelines...).
Может ли кто-нибудь (инсайдеры MSFT, возможно?) пролить свет на это расхождение?
Как ваша команда справляется с этим? Следуя StyleCop? Руководства по разработке рамок? Игнорирование стиля вообще? Выпечка собственного стиля?
В блоге, который я читал об этом (я не могу найти URL), было сказано: основополагающие принципы основаны и эволюционировали от С++-ориентированности (все они опытные разработчики на С++), в то время как руководящие принципы stylecop обеспечивают более современную новую С# только ориентировку... Оба в порядке, принимайте решение самостоятельно... Я лично использую элементы StyleCop
Эта статья команды stylecop точно объясняет, что вы просите, я думаю. http://blogs.msdn.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx
И чтобы ответить на вторую часть вашего вопроса, наша команда только начала использовать StyleCop, используя все правила (некоторые выбирают, какие из них использовать). Единственное, что мне не нравится, - это дополнительное время, которое требуется, но использование инструмента, такого как StyleCopForResharper, делает его намного быстрее. Я действительно раздражался, когда люди писали код, который выглядел иначе, чем я бы написал, но теперь, когда мы используем StyleCop, каждый код выглядит одинаково. Больше не кусайте свою губу о раздражающих вещах, которые люди делают
Мы используем StyleCop для всего нашего кода, и, кроме нескольких мелких мелочей, большинство его стандартов, которые я чувствую, приводят к самому читаемому коду. Многие из его стандартов были в значительной степени обсуждены в Microsoft и получили отзывы от сообщества, и, хотя не ожидается, что все согласятся со всем, вероятно, это лучший "стандарт" (особенно, поскольку он позволяет автоматически валидация и автоматическая коррекция с помощью плагина StyleCop для ReSharper).
Если есть какие-то вещи, с которыми вы категорически не согласны, Джейсон Аллор, который поддерживает этот инструмент, довольно открыт для предложений вокруг определенных вещей, например, с авто-свойствами StyleCop изначально настаивал на...
public int Prop
{
get;
set;
}
... но мы подняли запрос на изменение, чтобы разрешить однострочные свойства (т.е. все в одной строке), поскольку оно не менее читаемо и занимает меньше места. Он сделал это изменение в течение нескольких дней.
Вы принимаете решение. Если вам нравятся некоторые части одной и некоторых частей другой, напишите свой собственный путеводитель по стилю. Если вам нравится один лучше, чем другой, выберите его.
Главное, чтобы выбрать стиль; нет никакого способа оценивать один над другим каким-либо строгим количественным образом.