Не вижу в этом ничего логичного. Открыли проект, нажали “применить стиль”, закоммитили, profit.

А вот нет кнопочки “применить стиль”, которая даёт приемлемый результат. Лучшие стилизаторы правят только 100% распознанные участки кода. Нетронутые участки кода требуют ручной правки. Худшие стилизаторы правят 100% кода, требуя последующей ручной правки всего кода.

Автоматический проверятор на continious integration сервере не даст забыть.

Именно. Только автоматика не ловит все.

Поэтому надо _везде_ применить одинаковый стиль.

Да откуда вы это взяли? Стиль выбирают _до_ написания кода.

Это всё в теории хорошо…

Переведите их из warning’ов в error’ы. Иначе действительно на них все будут забивать.

Нам вообще-то еще и работать надо. Есть более еффективные способы приложить свои усилия чем вычищать ВСЕ предупреждения. Опять же, на самом деле нужно вычистить только те предупреждения, что действительно скрывают за собой проблемы. Только вот как их распознать.

Выберите такой стиль, который поддерживается стилизатором.

Он не удобен, так как значительная часть исправлений портит код.

Либо error, либо конструкция является приемлемой.

Если бы компилятор мог 100% достоверно распознавать ошибки, то он бы не выдавал бы предупреждения как класс. А пока этого не случилось для предупреждений определены “уровни”, которые приблизительно отражают степень потенциальной опасности предупреждения.

Зачем? Просто не надо в одном и том же коммите исправлять стиль и менять логику работы кода.

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

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

Не вижу в этом ничего логичного. Открыли проект, нажали “применить стиль”, закоммитили, profit.

Разработчики возвращаются к насущным проблемам, все реже вспоминая про выбранный стиль (хотя и пытаясь, время от времени, ему следовать).

Автоматический проверятор на continious integration сервере не даст забыть.

После массовых правок кода, наиболее ретивые поклонники стиля наталкиваются на многочисленные конфликты при слиянии кода из разных веток.

Поэтому надо _везде_ применить одинаковый стиль.

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

Да откуда вы это взяли? Стиль выбирают _до_ написания кода.

Аналогичная вещь случается когда пытаются вычистить все предупреждения компилятора если их количество больше 10 на каждый исходный файл проекта.

Переведите их из warning’ов в error’ы. Иначе действительно на них все будут забивать.

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

Выберите такой стиль, который поддерживается стилизатором.

Аналогично, стилизатор должен позволять контролировать важность того или иного предупреждения. По мере уменьшения предупреждений определённого вида, их можно превратить в ошибки с тем, чтобы гарантированно избежать их появления в будущем.

Не согласуется с вашим же утверждением, что warning’и исправляться не будут. Либо error, либо конструкция является приемлемой.

Кроме всего прочего, в документ, описывающий выбранный стиль следует включить рекомендации о том, как избежать массовых правок кода при стилевых правках.

Зачем? Просто не надо в одном и том же коммите исправлять стиль и менять логику работы кода.

Под стилем имеется в виду только форматирование кода или что-то еще?

И форматирование, и именование переменных, и использование/не использование определённых конструкций. Всего по немножку. Всё это автомитически проверить не удается, но я хочу сказать, что то, что можно проевить автоматически должно проверяться автоматически.

Рецензирование кода, безусловно, помогает.

Если форматирование, то задача почти полностью решается через автоматические стайлеры. Если что-то более нематериальное (соглашения об именовании, например, вообще не проверишь автоматически), то помогает только процедура рецензирования кода. Чем более тшательно она проводится и для чем большей доли изменений является обязательной, тем лучше будет ситуация со стилем.

Еще может оказаться весьма полезным fxCop, надо только подобрать правильные набор проверок для конкретного проекта.

Теперь все проекты, включая старые, гарантированно в одном стиле.