StyleCop — статический анализатор C# кода на предмет соответствия стилю — был официально представлен публике в начале 2008 года. По IT-меркам это довольно давно, однако этот полезный инструмент почему-то до сих пор не получил широкую популярность (по крайней мере ту, которую заслуживает).
Ниже я постараюсь проанализировать причины, а также расскажу о новом плагине к StyleCop.
Почему StyleCop не очень популярен?
Помимо разработчиков, которых вообще не заботит стиль кодирования (здесь и далее речь пойдет только о языке C#), многих отпугивает слишком большое количество ошибок при настройках по умолчанию. На мой взгляд, это странно — если тебя волнует стиль кодирования, то вполне естественно проверить все настройки, решив для себя, какие из них подходят для соблюдения выбранного стиля.
Но здесь возникает вопрос — а что вообще понимается под стилем кодирования? Это какой-то единый стиль для всех, кто пишет на C#? Или каждая команда вольна выбирать его по своему усмотрению?
Мне кажется, что сама идея существования «единых» правил — утопична. В целом, есть некоторые тенденции, которых со временем начинают придерживаться все больше и больше разработчиков. Однако язык развивается, добавляются новые конструкции (а значит, и способов их использования становится все больше), и начинается новая волна обсуждений и споров.
Тем не менее, Jason Allor — создатель и главный идейный вдохновитель StyleCop — придерживается позиции, что правила стиля должны быть едиными для всех. В итоге эти правила и составляют те самые «настройки по умолчанию», которые часто останавливают тех, кто хотел бы использовать StyleCop.
Мне не хотелось бы провоцировать споры о конкретных правилах — в конце концов, предлагаемый StyleCop стиль используется некоторыми командами в Microsoft (а значит имеет определенный «коэффициент доверия»). Однако мой личный опыт показывает, что чаще всего работает принцип «локального стиля» — т.е. свой стиль принимается в команде, в отделе, или во всей организации, а затем неукоснительно соблюдается.
Здесь замечу, что если ваши соглашения заключаются только в устных договоренностях — можете считать, что никаких соглашений у вас нет. Принудительная проверка (например, в качестве одного из этапов сборки на build-сервере) — единственный гарант их соблюдения. Тут-то такие инструменты как StyleCop и показывают себя во всей красе.
Как можно исправить ситуацию?
К счастью, StyleCop имеет довольно развитую систему плагинов, что позволяет существенно расширять его функциональность (даже сам набор оригинальных правил технически оформлен как отдельный плагин). Но плагинов к StyleCop в публичном доступе не так много. А большинство из тех, которые можно найти, представляют собой несколько разрозненных правил и выглядят заброшенными.
Мне кажется, что StyleCop был бы более полезен, если бы позиционировался не как инструмент для соблюдения определенного стиля, а стал бы неким «конструктором», с помощью которого можно было бы контролировать соблюдения того стиля, который нужен именно вашей команде.
StyleCop+
Примерно с такими мыслями год назад я начал писать StyleCop+ — очередной плагин к StyleCop. Его основная идея была и остается неизменной — не навязывая конкретные правила, предоставить широкий спектр возможных проверок, позволяющих настроить свой собственный стиль.
Плагин неспешно писался в свободное время и постепенно обрастал новыми возможностями. В итоге, я решил поделиться своими наработками и начал публиковать его на CodePlex. Положительные отзывы показали, что работа была проделана не зря.
Ниже я хотел бы кратко рассказать об основных возможностях StyleCop+. Если вы уже используете StyleCop — они могут показаться вам интересными, если же нет — возможно, именно их вам и не хватало, а может они вдохновят вас на написание собственных расширений.
Advanced Naming Rules
История возникновения этих правил достаточно банальна — в нашей команде был принят m_field-стиль для полей классов (когда имена приватных полей начинаются с различных префиксов, в частности m_). StyleCop же поддерживает только this.field-стиль (когда приватные поля не имеют префиксов, но любое обращение к полям или методам класса должно сопровождаться обязательным this, чтобы отличать поля от, например, аргументов метода). Более того, StyleCop содержит и правило, запрещающее использование символов подчеркивания в именах вообще.
Повторюсь, я не берусь утверждать какой стиль лучше. Но реальность такова, что разные стили уже существуют (даже в .NET BCL можно наблюдать группы классов, написанных разными командами в разное время — и с разными стилями именования). А раз так — то инструмент для соблюдения стиля просто обязан учитывать все это многообразие.
Таким образом, в StyleCop+ появились правила, позволяющие настроить практически любую систему именования объектов. Функционально они полностью покрывают основные Naming Rules (SA13xx), так что последние можно просто отключить:
Способ конфигурирования этих правил во многом похож на аналогичные настройки в ReSharper — вам доступен широкий набор сущностей, для каждой из которых можно задавать свои шаблоны именования.
К примеру, следующее правило говорит, что имя должно либо начинаться с префикса m_, после которого следует имя в camelStyle (m_rulesMap), либо быть полностью записано в PascalStyle (RulesMap).
Как видно из картинки, в шаблонах именования можно использовать ряд макросов, описывающих наиболее распространенные стили капитализации.
Самих сущностей тоже довольно много, причем некоторые из них специально выделены отдельно. К примеру, кто-то может не захотеть переименовывать стандартные обработчики событий WinForms (такие, как buttonStart_Click) — а значит, им могут понадобится свои правила, не те, что для обычных методов. Или же кто-то может по-особому называть методы, являющиеся юнит-тестами (например, Setting_Null_Throws_Exception). А уж необходимость иметь разные правила для имен классов или полей в зависимости от модификаторов доступа и вовсе очевидна.
Раз уж в именах проверяется капитализация, то не обойтись и без задания собственного списка аббревиатур (здесь под ними понимаются любые сочетания заглавных букв, которые должны допускаться в качестве отдельного слова). Также недавно появилась опция, позволяющая следить за тем, чтобы имена некоторых производных классов, обязательно заканчивались на имя базового (например, это общепринято для Attribute, Exception, Stream и т.д., но кто-то может захотеть добавить и свои исключения).
More Custom Rules
Как и другие плагины, StyleCop+ содержит различные дополнительные правила для проверки стиля. Их пока не очень много, но те, которые существуют, довольно гибко конфигурируются (спасибо активным пользователям, предложившим множество интересных идей).
Для этих правил был создан отдельный интерфейс, позволяющий более дружелюбно редактировать настройки (в отличие от традиционного интерфейса на вкладке Rules, здесь настройки не ограничены флажками с булевскими значениями и относятся к самому правилу).
Extended Original Rules
Это экспериментальная возможность, в рамках которой StyleCop+ содержит правила, «паразитирующие» на оригинальных правилах StyleCop. Например, полезное правило SA1509: OpeningCurlyBracketsMustNotBePrecededByBlankLine в том числе запрещает и «встроенные» блоки кода.
// some statements
...
{
int a; // declaration of local variables required to set value of f1
...
this.f1 = ...;
}
{
int a; // declaration of local variables required to set value of f2
...
this.f2 = ...;
}
Его «правило-паразит» — SP1509 — содержит настройку, позволяющую разрешить такое написание. Ключевой момент состоит в том, что это правило не содержит собственного кода, дублирующего оригинальную проверку. Вместо этого «правило-паразит» запускает оригинальный код из StyleCop, но накладывает свои ограничения на результат (в приведенном примере оно не будет выдавать ошибку, если та вызвана «встроенными» блоками кода).
Вместо заключения
Если вы еще не используете StyleCop — обязательно попробуйте, он должен стать вашим must-have инструментом!
Если вам не хватает функциональности — пишите расширения или ищите существующие!
Что касается StyleCop+, он продолжает постепенно развиваться. Скачивайте, пользуйтесь, задавайте вопросы на CodePlex. А уж если так получится, что именно он побудит хотя бы одного разработчика начать пользоваться StyleCop — можно считать, что свою миссию этот проект выполнил на все 100%!
Удачи!
____________________
- http://stylecop.codeplex.com — StyleCop на CodePlex
- http://stylecopplus.codeplex.com — StyleCop+ на CodePlex
- http://blogs.msdn.com/b/sourceanalysis — блог Microsoft StyleCop
- http://devjitsu.com/blog — блог Jason Allor
