Чи добре переформатувати інший код розробника під час зміни / додавання до модуля?

Розвиваючись в груповій атмосфері та додаючи або змінюючи функції в деякій базі коду. Чи вважається образливим чи нечесним переформатувати попередній код розробника, щоб привести його до сучасних стандартів кодування? Я розумію, що стандарти змінилися і, ймовірно, продовжуватимуть змінюватися, але чи хтось із вас образиться, якби хтось зайшов і змінив форматування вашого коду?

Щоб було зрозуміло, я не говорю про зміну будь-якої логіки, просто возитися з вкладками та пробілами тощо.

EDIT: Я роблю це не лише заради стандартів кодування, це допомагає мені прочитати їхній код і довести його до цього часу, щоб я міг повністю зрозуміти логіку, що була реалізована до того, як почати змінювати критичні програми.

Я думаю, що це нормально, доки домовляються про стандарти. Однак одна нота обережності; майте на увазі, чи є потенціал, коли файл одночасно змінюється іншими. Якщо ви зробите їх об'єднання важче лише тому, що ви змінювали форматування, ви не будете дуже популярними.

Так, код повинен належати проекту. Доведення коду до стандартних допоможе зменшити технічний дефіцит проекту. Якщо ви його модифікуєте, ви зараз несете за це відповідальність. Що стосується старого коду, оригінальний розробник може більше не брати участь у проекті або нести нові обов'язки.

Коли ви робите подібні зміни, добре проводити перевірочні тести після переформатування. Якщо вони пройдуть, перевірте код перед тим, як змінити свою функцію.

EDIT: У контексті цього питання переформатування до стандарту є доцільним. За відсутності стандартів я рекомендував би виступати за стандарти та не переформатувати, поки не існують стандарти для формату. Переформатування на особистий смак / стандарти не повинно проводитися з кодом, що належить проекту.

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

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

Я думаю, що це хороша практика та необхідна частина обслуговування коду.

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

Я б із цим не мав жодних проблем і, певно, оцінював би це ... до тих пір, поки зміни не будуть "релігійними". Будь ласка, не проходьте всі мої заняття та перемістіть фігурні дужки до першого рядка методу. Якщо форматування є законним типом "різні штрихи для різних людей", то це трохи дратує, коли хтось заходить і накладає формат на код, який ви найчастіше редагуєте. Однак, якщо ви стаєте основним редактором цього конкретного модуля, то внесіть усі зміни форматування, які ви вважаєте за потрібне.

Так. Будь ласка, "виправте" код так, як вважаєте за потрібне. Так само, як кажуть прагматичні програмісти у своїй книзі «Прагматичний програміст» , немає розбитих вікон. Якщо код не дорівнює, я вважаю його розбитим вікном.

Існують різні сховища, які автоматично здійснюють переформатування під час реєстрації, а також невеликі речі, такі як зміна CR / LF спарювання на get, залежно від платформи, яка отримує джерело.

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

Ви можете запропонувати вашій увазі, що оскільки база коду стара, її слід заносити з холоду і переформатувати на сучасні стандарти все за один раз, що веде до світлого нового майбутнього коду скрізь.

Оскільки ви говорите про суто "форматування" питання (це означає, що ми не виправляємо помилки, але робимо це досить схожим на ваш власний стандарт), я думаю, це залежить від того, чи зберігає код оригінальний код чи ні.

Якщо розробник все ще працює над проектом - це грубо. Те, що може "виглядати" правильно вам, не те, що буде "виглядати" правильно для них, а зміна коду задля форматування не є ввічливою. Це також може витрачати багато часу.

Я працював над проектом одного разу з ДУЖЕ власницьким розробником. Протягом багатьох років я розробив дуже методичний спосіб форматування свого коду, який, на мою думку, легко читається, менш схильний до неявних помилок та самодокументування. Цей хлопець, з іншого боку, віддав перевагу використанню всіх неявних функцій із довгими рядками, які поширювались 300 символів, щоб вам прочитати, бо вам довелося мати 30-дюймовий монітор, щоб його прочитати, оскільки він вважав, що кількість ліній важливіша за читаність. через мій код міняючи його на "бажаний стандарт" ... поки я ще паралельно розвивався! Я прийшов наступного ранку, щоб знайти роботу, що вартує двох днів, відформатовану на його безлад. Це було грубо і марна трата часу.

Тепер, якщо розробник пішов і у вас є "кращий стиль", займіться цим.

Завжди автоматично відформатуйте код, якщо ваш IDE може це зробити.

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

Наприклад, у затемненні, ви можете спочатку запустити формат і організувати імпорт для всієї бази коду. Тоді не забудьте ctrl + alt + f перед збереженням.