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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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