Форматирование кода плохо при использовании VCS?

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

Недавно я установил инструменты питания VS, у которых есть опция «Форматировать при сохранении», и внес изменения в файл, который ранее не форматировался. Вице-президент по разработке только что пришел ко мне и сделал выговор за форматирование, поскольку в инструменте слияния он показывает, что изменился почти весь файл, а не просто строка или две (поэтому он не может точно увидеть, что я легко изменил), и сказал мне отключить формат при сохранении в будущем. Хотя я понимаю эту проблему, мне иногда трудно разобраться в коде, который не отформатирован, и в любом случае IMO должен быть правильно отформатирован все время. Обратите внимание, что я не просто переформатирую вещи по прихоти, но когда я пишу код, я либо использую электроинструмент, либо нажимаю команду клавиши для форматирования текста, чтобы его было легче читать, а в SVN это отображается как модификация.

Поэтому я спрашиваю, всегда ли форматирование кода на самом деле плохо? Являются ли его опасения более обоснованными, чем обеспечение читабельности кода?

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

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

Нет, форматирование кода очень важно . Тем не менее, коммиты должны быть сделаны в двух группах:

1. Косметические изменения - все, что делает код более читабельным.
2. Другие изменения - все остальное, что влияет на код.

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

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

Я тоже форматирующий нит-сборщик, так что вот несколько советов:

• Обязательный первый шаг: попросите команду согласовать некоторые базовые стандарты форматирования, такие как табуляция и пробелы, позиции фигурных скобок, стили комментариев и т. Д. Теперь ваши изменения форматирования не станут полной неожиданностью для всех, и вы не сделаете шаг на любых пальцах.

• Очистите форматирование только вокруг кода, который вы меняете. Если вы вносите изменения только в одну функцию, то очистите эту функцию. По крайней мере, со временем у вас будет более красивый код.

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

• Получите хороший инструмент сравнения, который может сделать зависящую от языка маркировку существенных изменений и незначительных изменений. Мой любимый diff Beyond Compare отмечает реальные изменения кода в одном цвете, а пробелы / комментарии - только различия в другом.

отредактируйте еще один совет:

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

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

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

Вы заметите, что во всех случаях я имею в виду стандарты командного кодирования. Я твердо верю в разумные, согласованные стандарты кодирования для команды. Если они у вас есть, то первоначальный разработчик должен вернуться и очистить свой код, чтобы придерживаться стандартов команды, вы не должны делать это за их спиной. Если у вас нет стандартов (и вы должны это делать), то вам не следует изменять код другого члена команды, чтобы придерживаться своей философии, особенно за его спиной. Помните, что вы являетесь частью команды, и хотя стандарты кодирования важны, равно как и доверие и уважение между членами команды.