Должен ли я совершить косметические изменения?

Question

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

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

• Удаление и сортировка использований (в .NET, импорт в Python, включает в себя C ++)
• Правильные отступы, интервалы и разрывы строк

Answer 1

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

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

Answer 2

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

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

Answer 3

Не фиксируйте их вместе с несвязанными исправлениями.

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

Вы можете использовать префикс, например [cleanup].

[cleanup] Removed some whitespace
[cleanup] Changed format
Fixed some major bug.
[cleanup] Corrected indentation

Answer 4

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

В проектах, в которых есть наша команда, я стараюсь вносить подобные изменения самостоятельно, чтобы они не мешали «реальной работе».

Я чувствую, что важно исправить все, что «не так», с помощью кодовой базы, даже если это чисто незначительные вещи, такие как отступ

Answer 5

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

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

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

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

Answer 6

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

Удачи.

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

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

Answer 7

Есть пара вопросов.

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

Другими словами, не меняйте код ради изменений. Всегда добавляйте некоторое значение к коду в процессе.

Теперь, если эти изменения способствуют облегчению обработки кода вами и другими пользователями, сделайте это. Такие вещи, как соблюдение стандартов именования, рефакторинг хитрого кода и т. Д. Но получите задание для этого, чтобы ваш руководитель проекта мог сказать: «Да, это хорошо, потратить на это 2 часа и вернуться ко мне».

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

"Хорошо, вы исправили ошибку 7711, а также изменили около 100 других файлов. Хорошо, так что же здесь на самом деле исправление?"

Answer 8

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

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

Answer 9

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

Answer 10

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

ИМО, ребята, вам не хватает инструментов для кодирования, таких как PMD, JIndent и т. Д.код.Некоторые IDE, такие как Netebeans, показывают эти «проблемы» как предупреждения.Таким образом, это не случайное / личное изменение в соответствии со стандартами.