Существуют незначительные изменения стиля кодирования, которые я часто хочу передать исходному элементу управления, но теперь журнал изменений заполнен теми изменениями, которые не влияют на функциональность кода.Должен ли я совершать косметические изменения?
Что я должен делать в следующий раз я должен исправить незначительные вещи, как:
Если вы меняете файл кода, я не понимаю, почему вы не захотите совершать и делиться этими изменениями. Если вы этого не сделаете, вы рискуете, что кто-то другой их исправит, а затем столкнется с вашим.
Если они не являются изменениями, которые другие пользователи хотят в кодовой базе, возможно, вы должны спросить себя, почему вы тратите время на их запись.
Хорошая точка. , , –
И если вы не просто будете раздражать всех с бесконечными пробелами/косметическими различиями. –
@ Dominic теперь вы говорите, что я не должен .. –
Являются ли эти «незначительные» вещи исправлениями? Если да, зафиксируйте их. Если нет, не делайте этого.
Действительно, это зависит от того, что вы и ваша команда считаете важным.
Зафиксируйте их следующим большим изменением в качестве опоры. По крайней мере, это то, что я сделал бы.
-1 - это сделает невозможным то, что на самом деле изменилось в ваших больших изменениях. Пространственные/косметические изменения всегда должны быть раздельными, поэтому фактические изменения легче увидеть. –
Но тогда, возможно, слияние простого исправления с другой веткой, выпущенной версией, может вызвать шум, потому что набор изменений содержит множество несвязанных изменений. –
@ Dominic, Lasse: Ребята, вы правы ... Я полностью пропустил, что есть также набор изменений для каждой фиксации, которая будет переполнена изменениями пробелов ... извините. – Bobby
Не связывайте их вместе с несвязанными исправлениями.
Я бы передал их, но добавьте определенное предопределенное ключевое слово в сообщение фиксации. Сообщения с этим ключевым словом могут быть проигнорированы при создании журналов изменений.
Например, вы можете использовать префикс, например [cleanup].
[cleanup] Removed some whitespace
[cleanup] Changed format
Fixed some major bug.
[cleanup] Corrected indentation
[косметический] также подходит как ключевое слово, это означает, что это очистка, которая не выполняет никаких функциональных изменений. – florisla
В проектах, где я являюсь единственным разработчиком, я стараюсь делать подобные исправления вместе с другими изменениями кода.
В проектах, где есть команда из нас, я стараюсь самостоятельно совершать подобные изменения, чтобы они не скрывали «настоящую работу».
Я чувствую, что важно исправить все, что «неправильно» с помощью кода, даже если это чисто второстепенные вещи, такие как отступы.
Соблюдайте их, с соответствующим комментарием коммита, чтобы было легче игнорировать при пересказе через список изменений.
Не совершайте их в той же операции, что и изменение функциональности. Таким образом, если вы что-то сломаете, легче сузить то, что сломало его, и легко восстановить только рефакторинг, если это необходимо.
Это действительно важно. Переменять пробельные изменения вместе с функциональными изменениями опасно. Это затрудняет людям выяснение того, что действительно изменилось. И, как и все остальные, убедитесь, что косметические изменения легко узнаваемы из сообщений об их фиксации. (Вы используете сообщения фиксации при каждой фиксации, верно?) – mcv
Мне нравится совершать часто. Конечно, в любое время происходят заметные изменения. Это легко. Если вы начнете разделять фрагменты кода и попытаться совершить сделку раньше, чем позже, вы в конце концов забудете совершить что-то очень важное.
Вкратце: часто фиксируйте и ВСЕГДА документируйте изменение. Когда произойдет ОГРОМНОЕ изменение, пометьте его.
Я думаю, что это зависит от вашей рабочей среды и того, как другие, работающие над одним проектом, хотят иметь дело с тем, что может отличаться.
Итак, моим общим предложением было бы спросить людей, работающих с одним и тем же кодом, и придумать руководство для подобных случаев. Вы можете обнаружить, что люди не возражают против регистрации из-за косметических изменений или что они предпочитают жить с немного «недобросовестностью», а не с суматошными журналами изменений.
Определенный ориентир, который является прозрачным для всех, является лучшим способом справиться с этими вопросами и избежать путаницы в будущем.
Лично мне нравится приписывать код и не возражать против регистрации из-за чисто косметических изменений. Однако, если это всего лишь несколько интервалов и разрывов строк, я бы, вероятно, просто допустил это и изменил бы это только в том случае, если бы я работал над одним и тем же файлом кода. Я часто удаляю и сортирую, потому что я нахожу это сбивающим с толку, если есть целая куча привычек, которые не имеют смысла, но это только я.
Определенно зафиксировать их. Если вы передадите их вместе с реальными изменениями кода, и вам придется откатить эти изменения, вы потеряете свои косметические исправления.
В идеале, фиксации должны быть похожими на транзакции базы данных: кусок связанного рабочего кода, который можно отбросить, не затрагивая остальную часть системы.
Существует несколько проблем.
Во-первых, не вносите изменений в код, потому что вам скучно и не хватает реальных задач. Если это так, поговорите с вашим менеджером проектов и получите некоторые реальные задачи, назначенные вам, что-то со значением.
Другими словами, не изменяйте код для изменения. Всегда добавляйте некоторое значение в код в процессе.
Теперь, если эти изменения способствуют упрощению обработки кода, вами и другими, выполните их. Такие вещи, как обеспечение соблюдения стандартов именования, реформаторский критический код и т. Д. Но возьмите задачу для этого, чтобы ваш менеджер проекта мог сказать «Да, это хорошо, потратьте 2 часа на это и вернитесь ко мне».
Завершите изменения, когда закончите с ними. Не ломайте их вместе с какой-либо реальной задачей, которую вы закончили непосредственно перед ними, или следующей, она сделает слияние исправлений между ветвями, обзорами кода и просто общим просмотром кодов, которые трудно выполнить.
«Хорошо, поэтому вы исправили ошибку 7711, а также изменили около 100 других файлов. Приятно, так что же на самом деле это ошибка?»
Я думаю, что когда у вас есть команда разработчиков, работающих над одним и тем же кодом, самое главное - договориться о косметическом стиле для кода. Итак, ваша первая задача - попытаться заставить всю команду согласиться на стиль кодирования.
Удачи.
После того, как вы это сделали, совершите косметические изменения так часто, как вы хотите, чтобы напомнить людям придерживаться стиля.
В разделе «Полный код» содержится замечание о достоинствах разных стилей кодирования. Если вы можете заставить свою команду прочитать раздел перед вашей встречей в стиле кодирования, это может помочь вытащить вас из собрания живым сосредоточить внимание на обсуждении.
Я почти полностью согласен. Во-первых, у вас есть стиль кодирования, на который все согласны. Однако часто совершение косметических изменений не сделает вас популярными среди других разработчиков в вашей команде. Вместо этого я предпочел бы сделать полную очистку стиля кодирования и зафиксировать ее за один раз. В производственном цикле могут быть определенные моменты времени, когда такая очистка может быть выполнена. –
@nikai: хороший пункт. Я предполагаю, что некоторые повторные коммиты на раннем этапе могут впоследствии сохранить повторную работу по очистке кода (люди действительно должны чему-то учиться), но, конечно, много раз в производственном цикле, когда стиль кодирования не является приоритетом. –
Если изменения относятся к вещам, которые могут быть спорными (например, положение скобок), то убедитесь, что вы согласовали стиль кода с остальной частью вашей команды. Не просто измените его на свой собственный предпочтительный стиль, а затем проверьте его. В противном случае кто-то другой может изменить его и проверить его изменения, а затем изменить его на свой путь ...
Не совершайте просто ради совершения. Я обычно добавляю те для кода, над которым я работаю. Например, если я исправляю ошибку в методе A, я также должен сделать все косметические изменения.
IMO вы, ребята, не хватает инструментов кодирования, таких как PMD, JIndent и т. Д., Которые заботятся об этих проблемах при кодировании. Некоторые IDE, такие как Netebeans, отображают эти «проблемы» как предупреждения. Поэтому его не случайные/личные изменения соответствуют стандартам.
Возможно, это должно получиться «субъективным» тегом? –
Обязательно часто, для чего нужны инструменты scm. По моему мнению, ни в коем случае журнал scm не должен рассматриваться как правильный ChangeLog –
, добавленный «субъективный» тег. – 2010-01-12 13:16:11