Переформатирование и контроль версий

Форматирование кода имеет значение. Даже отступы имеют значение . И последовательность важнее, чем незначительные улучшения. Но проекты , как правило , не имеют четкой, полной, поддающейся проверке и вынужденное руководство по стилю от 1 -й день, и значительные улучшения могут прийти в любой день. Может быть, вы найдете это

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

может быть лучше написано как / лучше написано, чем

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

работая над добавлением дополнительных столбцов в запрос. Возможно, это самый сложный из всех четырех запросов в вашем коде, или тривиальный запрос среди тысяч. Неважно, насколько сложен переход, вы решаете, что оно того стоит. Но как вы отслеживаете изменения кода при основных изменениях форматирования? Вы можете просто сдаться и сказать «это точка, с которой мы начинаем снова», или вы можете переформатировать все запросы во всей истории хранилища.

Если вы используете распределенную систему контроля версий, такую ​​как Git, вы можете вернуться к первому коммиту и переформатировать свой путь оттуда к текущему состоянию. Но это большая работа, и всем остальным придется приостановить работу (или быть готовым к матери всех слияний), пока она продолжается. Есть ли лучший способ изменить историю, который дает лучший из всех результатов:

• Одинаковый стиль во всех коммитах
• Минимальная работа слияния

?

Для пояснения, речь идет не о передовых практиках при запуске проекта, а о том, что следует делать, если крупный рефакторинг был признан Good Thing ™, но вы все еще хотите отслеживать историю? Никогда не переписывать историю - это хорошо, если это единственный способ гарантировать, что ваши версии всегда работают одинаково, но как насчет преимуществ чистого переписывания для разработчиков? Особенно, если у вас есть способы (тесты, определения синтаксиса или идентичный двоичный файл после компиляции), чтобы гарантировать, что переписанная версия работает точно так же, как и оригинал?

Выполните переформатирование как отдельные коммиты. Это будет минимально влиять на историю, и вы сможете сразу увидеть, какие коммиты просто переформатируют, а какие фактически меняют код. Он может быть искаженным git blameи похожим, но если он указывает на фиксацию только для переформатирования, довольно просто искать предыдущее изменение перед этим.

Не переписывайте историю VCS: это противоречит принципам VCS.

Не пытайтесь автоматизировать исправление форматирования: это лечит симптомы, а не реальную проблему (= разработчики не следуют стандартам кодирования).

Определите стандарт кодирования и рекомендации по форматированию в общем документе и получите согласие всех разработчиков.

Вы упоминаете Git, который великолепен, потому что он распространяется. С DVCS очень легко применять лучшие практики через рабочий процесс привратника . Привратники отклоняют предложения о слиянии (= запросы на получение в Git), которые не соответствуют общим правилам. И я имею в виду отклонить жирным шрифтом, иначе нарушитель кодера не потрудится следовать правилам и продолжит повторять те же ошибки.

Эта техника хорошо работает для меня. Кодеры хотят, чтобы их работа была объединена, поэтому после нескольких ошибок в начале они начинают следовать правилам.

Что касается исправления существующей кодовой базы ... Я рекомендую делать это постепенно, возможно, модуль за модулем, или, как это имеет смысл для вашего проекта. Проверяйте внимательно на каждом этапе. Это может звучать глупо, но ошибки случаются даже с такими банальными изменениями, как просто форматирование, так что будьте готовы к небольшим неприятностям на дороге.

Ответ на ваш настоящий вопрос: «Вы не делаете». Я не знаю ни одного текущего инструмента SCM, который мог бы отслеживать изменения в логике от кода, отформатированного одним способом, через значительное изменение форматирования и через дальнейшие изменения после того, как код отформатирован новым способом. И, вы знаете это, потерять историю на куске кода - это не хорошо.

Соответственно, я собираюсь немного противоречить вашему первому предложению. Форматирование кода не имеет значения , что много. Довольно приятно, но мы здесь не для этого. Я, как и любой другой, понимаю, что получить дамп в чей-то старый адский странный код варианта K & R с отступами в два пробела - отстой (1), но ... форматирование на самом деле не является препятствием для понимания происходящего, если только это не является чем-то исключительным патологический. И в этом случае у вас все равно возникнут проблемы с изменением кода, и вам не следует об этом беспокоиться.

Следовательно, не стоит вносить изменения в установленный код СТРОГО, чтобы переформатировать его. Изменение имен переменных, разбиение длинных функций, все эти хорошие вещи рефакторинга, которые изменяют содержимое, да, но не просто переформатирование.

1) - Когда-то я владел средством просмотра буфера обмена Windows. Все это было одно, 150k, модуль C. Я нашел место, где разные люди использовали, я думаю, пять разных стилей скобок в пределах тридцати строк друг от друга. Но этот раздел вещей работал. Я носил распечатку этого куска кода в течение десяти лет, но я не совал его, потому что эта история имела значение, и этот код был как минимум в трех исходных деревьях (Windows 3.x, NT, future 95), которые все жили в разных зданиях.

Но как вы отслеживаете изменения кода при основных изменениях форматирования?

Форматирование изменений являются изменения кода; относитесь к ним так же, как к любым другим изменениям в вашем коде. Любой, кто работал над значимым проектом, вероятно, видел ошибки и другие проблемы, которые были созданы, когда кто-то решил «просто» переформатировать некоторый код.

Но это большая работа, и всем остальным придется приостановить работу (или быть готовым к матери всех слияний), пока она продолжается.

Почему вы должны переформатировать все одновременно? Особенно, если переформатирование не меняет смысла кода, вы должны иметь возможность переформатировать файлы по отдельности и проверять их по мере продвижения. Лучше попросите всех в вашей команде договориться о стиле (иначе все равно нет смысла переформатировать) и попросите всех позаботиться о переформатировании в ходе своей другой работы. Через некоторое время вы охватите большую часть кода, не нарушая остальную часть проекта.

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

1. Переформатировать код на коммит-хук

Изначально сложно изменить код после того, как они его отправили, но если ваша процедура переформатирования (например, astyle ) не повредит коду, то это безопасная операция. Со временем вся команда поймет, что весь код в конечном итоге выглядит одинаково. Понятно, что комплексные юнит / автоматические тесты гарантируют, что ничего не сломалось.

2. Единовременное переформатирование всего кода

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