Как устранить несоответствие между «стилем StyleCop C #» и «стилем разработки руководящих принципов C #»?

Question

Прочитав Приложение A, «Соглашения о стилях кодирования C #» великой книги «Руководство по разработке структуры» (2-е издание от ноября 2008 г.), я не совсем понимаю, какой стиль кодирования использует Microsoft для внутреннего использования / рекомендации. 1001 *

Запись в блоге Краткая история стиля C # претензий:

На самом деле, различия между "стилем StyleCop" и "стилем руководящих принципов разработки фреймворка" относительно незначительны

На мой взгляд, различия довольно заметны. В StyleCop сказано, что открывающая скобка должна быть на отдельной строке, а в Framework Design Guidelines - после вступительного слова. В StyleCop говорится, что за всеми ключевыми словами должен стоять пробел, а в Руководстве по разработке инфраструктуры говорится: «Избавьтесь от всех пробелов» (даже вокруг двоичных операторов).

Я нахожу это правило из книги «Руководства по разработке структуры» особенно ироничным (стр. 366, 6-е правило сверху):

Не использовать пробелы перед операторами управления потоком

Right: while(x==y)
Wrong: while (x == y)

Это явно означает, что стиль StyleCop неправильный (пробел после ключевого слова while, пробел до и после двоичного оператора равенства).

В конце код, отформатированный с использованием стиля StyleCop, имеет совершенно другое «ощущение», чем код, отформатированный с использованием стиля Framework Design Guidelines. Следуя стилю Руководства по проектированию платформы, нужно будет отключить несколько правил (И нет правил, которые проверяли бы соответствие стилю Руководства по проектированию платформы ...).

Может ли кто-нибудь (возможно, инсайдеры MSFT) пролить свет на это расхождение?

Как ваша команда справляется с этим? Следующий StyleCop? Руководство по разработке рамок? Игнорируя стиль вообще? Выпекаешь свой стиль?

Answer 1

Эта статья команды stylecop объясняет именно то, что вы спрашиваете, я думаю. http://blogs.msdn.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

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

Answer 2

В блоге, который я читал об этом (кажется, я не могу найти URL) было сказано: руководящие принципы фреймворка основаны и развиты на руководящих принципах C ++ (все они являются опытными разработчиками C ++), в то время как руководящие указания stylecop представляют собой более современное руководство на C # только И то, и другое хорошо, принимайте решение самостоятельно ... Я лично использую StyleCop

Answer 3

Мы используем StyleCop для всего нашего кода, и, за исключением нескольких мелких недоразумений, большинство его стандартов, по моему мнению, ведут к наиболее читабельному коду. Многие из ее стандартов активно обсуждались в Microsoft и получили обратную связь от сообщества, и хотя не ожидается, что все согласятся со всем, вероятно, это лучший из существующих «стандартов» (особенно потому, что он позволяет автоматически проверка и автоматическое исправление с помощью плагина StyleCop for ReSharper).

Если есть какие-то вещи, с которыми вы категорически не согласны, Джейсон Аллор, который поддерживает инструмент, вполне открыт для предложений по определенным вещам, например, с автоматическими свойствами, которые первоначально настаивал StyleCop ...

public int Prop
{
    get;
    set;
}

... но мы подняли запрос на изменение, чтобы разрешить однострочные свойства (т. Е. Все в одной строке), так как он не менее читабелен и занимает меньше места. Он сделал это изменение в течение нескольких дней.

Answer 4

Вы принимаете решение. Если вам нравятся некоторые части одной и некоторых частей другой, напишите свое собственное руководство по стилю. Если вам нравится один лучше, чем другой, выберите его.

Главное, что нужно сделать, это выбрать стиль; нет никакого способа оценить одно над другим любым количественным способом.