Можно ли переформатировать код другого разработчика при изменении / добавлении в модуль?

13

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

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

РЕДАКТИРОВАТЬ: я делаю это не только ради стандартов кодирования, это помогает мне прочитать их код и обновить его, чтобы я мог полностью понять логику, которая была реализована, прежде чем я начну модифицировать критические приложения.

wfoster
источник
6
Включить автоматический «формат при сохранении» для всех. Все используют одни и те же согласованные настройки. Через некоторое время весь код нормализуется.
1
Там может быть точка, где это идет далеко. У меня был сотрудник, который переформатировал все добавленные разрывы строк, которые не были необходимы или даже актуальны, насколько я был обеспокоен. Лично, если он не читается или код не стал моей основной обязанностью, я оставляю форматирование в покое, если я не делаю другие изменения.
SoylentGray
1
Если вы кодируете в c #, то придерживайтесь StyleCop. Если на других языках, то попробуйте выбрать хороший, непредвзятый инструмент.
Работа
5
Это "я меняю форматирование ... потому что я думаю, что это должно выглядеть по-другому" ... или это "я меняю форматирование ... слишком соответствует стандартам " ... совершенно разные вопросы
WernerCD
1
@ Torbjorn Я бы не стал рассматривать ветку, которая исправляет форматирование в каждом файле, 1 файл на коммит, историю убийств. Тем не менее, исправить это во время того же коммита просто плохо. (Я думаю, они могли бы использовать что-то вроде git addвыборочной фиксации частей, но я думаю, что большинство людей используют эквивалент svn commitили git commit -a)
альтернатива

Ответы:

19

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

Джереми Маллин
источник
10
Первое предложение здесь важно. Убедитесь, что вы действительно следуете согласованным стандартам, а не просто вносите изменения, потому что они вам нравятся.
Томас Оуэнс
5

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

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

РЕДАКТИРОВАТЬ: В контексте этого вопроса уместно переформатировать в стандарт. В отсутствие стандартов я бы рекомендовал защищать стандарты и не переформатировать, пока не появятся стандарты для формата. Переформатирование в соответствии с личным вкусом / стандартами не должно выполняться с помощью кода, принадлежащего проекту.

BillThor
источник
2
+1 за «проверьте код, прежде чем вносить изменения в свои функции»
bdoughan
1
Еще раз +1 за «проверить изменения форматирования перед внесением изменений в вашу функцию» и «хорошо запускать проверочные тесты после переформатирования». В идеале, мы должны запускать проверочные тесты перед каждой проверкой.
leed25d
На самом деле, неважно, переформатируете ли вы до или после изменений. Важно то, что эстетические патчи должны храниться отдельно от функциональных патчей -> если эстетический патч изменил функциональность, он не был предназначен и может считаться ошибкой; это делает функциональные исправления более легкими для просмотра (потому что меньше).
Матье М.
@Matthiew M: Верно, но в большинстве случаев они будут сделаны в первую очередь для улучшения обслуживания перед обслуживанием. Немногие разработчики успеют сделать это после свершившегося факта. Кроме того, если код необходимо обновить для прохождения автоматических проверок регистрации, его необходимо сначала переформатировать, чтобы сохранить разделение эстетических и функциональных исправлений.
BillThor
3

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

Уэйн Молина
источник
ОП спросил о переформатировании, а не о рефакторинге.
Quant_Dev
Я знаю; Я сказал, что считаю, что это также включает переформатирование :)
Уэйн Молина
2

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

RKitty
источник
2

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

Я бы порекомендовал проверить изменения форматирования в одном коммите в системе управления версиями и функциональные изменения в отдельном коммите, чтобы помочь себе и другим понять, что произошло.

semaj
источник
1
+1 за отдельные коммиты. Попытка выяснить, какие изменения кода были сделаны в коммите, когда код был переформатирован в то же самое время, является PITA. Ваши инструменты сравнения бесполезны, если каждая строка в файле изменилась.
Дэйв Кирби
2

У меня не было бы никаких проблем с этим, и я, вероятно, был бы признателен ... если изменения не являются "религиозными". Пожалуйста, не проходите все мои уроки и не перемещайте фигурные скобки в первую строку метода. Если форматирование является допустимым типом «разные штрихи для разных людей», то это немного раздражает, когда кто-то входит и навязывает формат наиболее часто редактируемому коду. Однако, если вы станете основным редактором этого конкретного модуля, внесите любые изменения форматирования, которые вы считаете нужными.

Морган Херлокер
источник
1

Да. Пожалуйста, "исправьте" код по своему усмотрению. Так же, как прагматичные программисты говорят в своей книге «Прагматичный программист» , нет разбитых окон. Если код не соответствует норме, я считаю его разбитым окном.

mpenrow
источник
1

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

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

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

Патрик Хьюз
источник
1

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

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

Однажды я работал над проектом с ОЧЕНЬ одержимым разработчиком. За эти годы я разработал очень методичный способ форматирования своего кода, который, на мой взгляд, легко читается, менее подвержен неявным ошибкам и самодокументированию. Этот парень, с другой стороны, предпочитал использовать все неявные функции с длинными строками, которые имеют ширину 300 символов, поэтому для его чтения нужно было иметь 30-дюймовый монитор, потому что он считал, что количество строк важнее, чем читаемость. Он потратил полдня взорвав мой код, изменив его на «предпочтительный стандарт» ... пока я еще продолжал разрабатывать параллельно! Я пришел на следующее утро, чтобы найти двухдневную работу, отформатированную в его беспорядке. Это было грубо и трата времени.

Теперь, если разработчик ушел, и у вас есть «лучший стиль», сделайте это.

Джордан Пармер
источник
0

Всегда автоформатируйте код, если ваша IDE может это сделать.

  • Предотвращает внесение изменений в форматирование вручную в долгосрочной перспективе
  • Профиль форматера должен быть согласован между всеми разработчиками (выбрать по умолчанию? -)
  • Сделайте форматирование кода и организацию импорта привычкой при сохранении файла

Например, в eclipse вы можете сначала запустить средство форматирования и организовать импорт для всей базы кода. Затем не забудьте нажать Ctrl + Alt + F перед сохранением.

JKJ
источник