Алексей Пахунов

Тема жёванная-пережёванная, так что я не буду подробно останавливаться на том, зачем нужен единый стиль кодирования в команде (или проекте). Основные тезисы:

• Унифицированный стиль кодирования упрощает сопровождение кода. Это, кажется, единственная причина, зачем он вообще нужен. Все остальное, включая меньшее количество мигреней в минуту на одного эталонного разработчика, – побочные эффекты, направленные опять же на упрощение (читай – повышение эффективности) сопровождения кода.
• Кажется, нет никакой разницы между разными стилями с точки зрения легкости понимания и написания кода. Любой выбранный стиль, будучи принят в команде упрощает сопровождение кода, при условии, что он один и используется.
• Единственный способ выработать единый стиль – диктатура в том или ином виде. Можно месяцами спорить о том, где правильно ставить скобки, какие отступы должны быть, можно ли использовать две пустые строки в качестве разделителя и т.д. и т.п. В один прекрасный момент терпение лопается и волевым решением назначается «правильный» стиль.

И вот, скажем, ваша команда достигла этой точки: стиль выбран, в репозитории сидит куча кода, который нужно переписать в соответствии с выбранным стилем. Даже если учесть, что львиная доля правок будет носить косметический характер, их общее количество, необходимое для достижения заветной цели, очень велико. Логичное решение, которое принимает любая вменяемая команда – постепенный переход; вместе с нормальными исправлениями разработчики будут править стиль исправляемого участка кода. На этом почему-то все успокаиваются.

Далее все происходит по одному из двух сценариев:

1. Разработчики возвращаются к насущным проблемам, все реже вспоминая про выбранный стиль (хотя и пытаясь, время от времени, ему следовать).
2. После массовых правок кода, наиболее ретивые поклонники стиля наталкиваются на многочисленные конфликты при слиянии кода из разных веток; недолго чешут затылки, понимая, что регулярная морока с конфликтами им совсем не улыбается и решают, что ну его на фиг. Далее всё следует по сценарию №1.

Почему так случается? Очевидно потому, что факт выбора стиля никак не влияет на его интеграцию в процесс написания кода. Типичное «стиль выбран, давайте весь новый код писать в новом стиле» не работает. Аналогичная вещь случается когда пытаются вычистить все предупреждения компилятора если их количество больше 10 на каждый исходный файл проекта. В конце концов, оказывается, что есть более приоритетные задачи, а код вроде и так работает.

Что можно сделать в такой ситуации?

• Во-первых, нужно выделить дополнительное время на правку кода. Иными словами будьте готовы, что каждое исправление будет занимать на 10% больше времени в течение N месяцев.
• Во-вторых, нужно, чтобы соответствие вносимых правок принятому стилю контролировалось автоматически, т.е. при каждом коммите/чекине. Казалось бы это очень просто реализуется, существует множество автоматических стилизаторов кода. На практике же выясняется, что либо выбранный стиль не поддерживается ни одним из них, либо стилизатор недостаточно толерантен к вариациям стиля, исправляя то, что исправлять не следовало.
• В-третьих, скрипты, используемые для запуска стилизатора, должны иметь гибкую систему фильтров, позволяющую задать какие файлы следует проверять, а какие должны игнорироваться при проверке. Фильтры должны храниться вместе в исходными файлами и быть доступны каждому разработчику, имеющему право коммитить/чекинить код. В самом начале должны проверяться, только новые файлы, а также существующие файлы, успешно проходящие проверку стилизатором. По мере внесения исправлений, исправленные файлы будут в список.
• Аналогично, стилизатор должен позволять контролировать важность того или иного предупреждения. По мере уменьшения предупреждений определённого вида, их можно превратить в ошибки с тем, чтобы гарантированно избежать их появления в будущем.
• Кроме всего прочего, в документ, описывающий выбранный стиль следует включить рекомендации о том, как избежать массовых правок кода при стилевых правках.

Вот такие вот мысли. Альтернатива всему этому – выработать иммунитет к любому, сколь угодно ужасному, стилю кода.

Программирование