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

Ответ 1

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

Тем не менее, вы должны стараться свести эти изменения к минимуму и делать это вообще, когда это необходимо и совместимо с любыми стандартами кодирования, которые используются в вашей компании/сообществе/проекте и т.д.

Ответ 2

Да! Да! В качестве отдельной фиксации, пожалуйста! (Эти виды исправлений, как правило, касаются большого количества кода, и люди должны знать, есть ли фиксация/changeet/patch/что-то там исключительно для переформатирования, без изменений, предназначенных для фактического кода.)

Ответ 3

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

Если это не ваш "код" (т.е. какое-то другое репо с другим стандартом форматирования придется объединять обратно, что вы делаете), вы можете воспользоваться git драйвер фильтра атрибутов и его механизм smudge/clean.

^{(Источник: Pro Git book: Настройка Git - Git Атрибуты)}

Вы можете применить свой формат к коду во время шага смазывания и повторно применить стандартный формат стандарта во время чистого шага.

Ответ 4

G'day,

Да. Но, пожалуйста, сделайте это как выделенный коммит с сообщением о том, что у вас

• изменено форматирование,
• запустите код через форматировщик кода, например. Perltidy, с примечанием о фактически используемой настройке,
• и др.

Ничего хуже, чем изменение форматирования в сочетании с функциональными обновлениями, поэтому различие между версиями обеспечивает низкое соотношение S/N!

В стороне, мне интересно, почему вы вносите изменения в форматирование существующего кода. Он не должен был быть проверен, если он был отформатирован в первую очередь!

Там нет ничего хуже, чем работать с кем-то, кто проходит через меняющийся форматированный источник только по другим причинам:

• они думают, что фигурные скобки принадлежат строке "if", или
• им не нравятся "обнимаемые elses", или
• и др.
• и др.

Такие религиозные выражения "одного истинного стиля" обычно противоречат отсутствию опыта кодирования и опыта работы в команде.

НТН

веселит,

Ответ 5

В ответах, уже приведенных здесь, хорошо объясняется, почему это может быть проблемой для фиксации изменений форматирования. Я думаю, что одним из решений будет поддержка редактора, позволяющая увидеть красиво отформатированный код, минимизируя при этом изменения форматирования при сохранении файла.

Я задал соответствующий вопрос об этом в...

• Есть ли текстовый редактор, который будет "печатать" для отображения без изменения основного текста?

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