Стандарты кодирования – важная составляющая процесса разработки программ. Без них невозможно разработать хорошо сопровождаемый код. Качественный код должен быть простым и читабельным, не содержать ошибок, время на его изучение должно быть минимальным, его расширение и модификация – удобным.
Стандарты кодирования нужны по двум причинам:
- Они позволяют избавить команду от пустых споров о вещах, которые не столь важны, сколько важно поддержание максимальной скорости работы.
- Без стандартов кодирования сложнее выполнять рефакторинг. Чем большие усилия потребуются человеку для того, чтобы внести в систему изменение, тем больше он будет стараться избежать этого изменения.
За основу стандарта кодирования для команды можно взять готовые примеры (например, в нашей организации были использованы соглашения по оформлению кода команды RSDN).
Но как показывает практика, подобные документы носят рекомендательный характер, к тому же в конкретных ситуациях среди разработчиков сразу рождаются споры (о наименовании переменных и методов, использования различных префиксов "m_", "_" и т.д.).
Принудительная проверка (например, в качестве одного из этапов сборки на build-сервере) — единственный гарант соблюдения стандартов. Тут-то такие инструменты как StyleCop и показывают себя во всей красе.
StyleCop анализирует исходные коды проекта, контролирует стиль и форматирование кода, вынуждая разработчиков соответствовать правилам и принятым стандартам. Предлагаемый StyleCop стиль используется некоторыми командами Microsoft. Проверка может быть запущена непосредственно из Visual Studio или выполняться при сборке проекта (интегрирована с MSBuild).
Правила StyleCop включают требования к расположению скобок, наименованию полей, методов и классов, написанию комментариев, отсутствию ненужных пробелов и многие другие.
Подробнее о правилах StyleCop написано в статье.
Интеграция StyleCop с MSBuild позволяет осуществлять проверку при каждой сборке проекта. Для этого в csproj-файл проекта необходимо добавить соответствующий тег:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...Contents Removed...
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(ProgramFiles)\MSBuild\StyleCop\v4.x\StyleCop.targets" />
...Contents Removed...
</Project>
В статье рассматривается интеграция StyleCop c SVN, но все перечисленные достоинства справедливы для любого варианта автоматизированной проверки (в том числе интеграции с MSBuild):
- Категоричность требования качества кода и соблюдение принятых стандартов
- Отсутствие отвлекающих споров на тему «как правильно расставить скобки» между разработчиками и концентрация на рабочих задачах
- Разгрузка старших программистов (нет необходимости объяснять младшим, как правильно оформлять код)
Конечно, попытки натравить StyleCop на существующий проект обернутся двухдневным исправлением тысячи стилистических ошибок, но большинство из них Resharper может исправить автоматически (плагин для интеграции с Resharper вошел в официальную сборку StyleCop, начиная с версии 4.5 RTW).
А к использованию в новых проектах StyleCop настоятельно рекомендуется.
StyleCop
Были использованы материалы из статей:
4 коммент.:
В IntellijIDEA можно просто включить автоматический рефакторинг перед коммитом.
Почему-то многие называют громким словом "рефакторинг" обычный реформат кода для соответствия заданному стилю форматирования кода.
Новый рефлекс: вместо Ctrl+S после каждой написанной фразы (современные редакторы сами все сохраняют) нажимать (например) Ctrl+Alt+L (реформат кода).
А автоматический реформат перед коммитом — зло. Непредсказуемо портит код, не показывая его программисту. Было бы лучше, если бы выводилось предупреждение, или происходил возврат в редактор.
Ммм... А какие минусы? Если нет минусов, почему тогда все не перешли на данный инструмент?
tdaniels
З.Ы. Не захотел принимать OpenID
минусы как всегда, требуется потратить время на убеждение всех разработчиков в важности общепринятых стандартов, а также на обучение использованию новых инструментов.
Отправить комментарий