Переваги та недоліки форсованого переформатування коду

Зараз я працюю в місці, яке, можливо, розглядає змушення розробників використовувати автоматизований формат-код для реєстрації версій. Я шукаю думки розробників щодо переваг та недоліків цього… як ви думаєте, що це допоможе чи завадить розробникам. Мій конкретний випадок стосується Java / JSP, але я думаю, що питання може стосуватися будь-якої мови.

Я думаю, що це дуже важливо зробити. Ось чому:

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

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

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

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

• Виключає можливість робити "краще", ніж автоформатування ... це скасує форматування чистішого пристрою. Прикладом цього можуть бути оголошення на основі стовпців, списки дискретних доповнень об'єктів тощо.
• Створює опір змінам конвенцій стилів, оскільки тепер вони створюватимуть великі оманливі різні зміни.
• Вилучає можливість робити будь-яке "спеціальне" форматування, коли альтернативний формат зробить код більш читабельним.
• Це пов'язує вас з використанням IDE, які підтримують саме потрібні функції переформатування. В іншому IDE відсутній один із необхідних варіантів, це спричинить хоча б деякі проблеми.
• Спільним сховищем коду, що можна записати, стає проблематичним із зовнішньою групою, якщо вони не використовують абсолютно ті самі конвенції формату, що і ваша група (Вони зазвичай є, але не завжди).
• Завжди є винятки, коли трохи інший формат, ймовірно, чистіший, ніж призначений стиль. Таким чином, автоматичне перетворення часто може приховувати наміри певних блоків коду, що ефективно так само добре, як і додавання дефекту до коду.

Простіше кажучи, неавтоматизований набір конвенцій встановлює мінімальні вимоги до стилю / читабельності, де автоматизовані конвенції встановлюють мінімум та максимум.

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

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

Основним недоліком є ​​втрата користувальницького форматування там, де це дійсно має значення.

Уявіть типову перевірку рівня безпеки, якщо () не вдасться, якщо якась із конкретних умов присутня, але не виконується ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Це читається завдяки розумному відступі, що відповідає логічній структурі умов.

Тепер ваш автоматизований інструмент не має поняття про логічне розділення різних умов на пов'язані рядки. Він не бачить причин, щоб кожен згрупував 3-4 умови в одному рядку і розділив наступну умову навпіл. Або це розділить його, один вираз порівняння на рядок. На екрані це може виглядати навіть гарніше, але логіка буде втрачена.

Я додав відповідь із недоліками, і підкину те, що вважаю великою перевагою.

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

Це для мене ледь не Святий Грааль кодування на основі конвенції ... Ви отримуєте переваги загального формату коду, але все ж дозволяєте підтримувати особисті переваги без конфліктів.

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

Розглянемо цей випадок:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Якщо ви тепер хочете додати журнал до випадку, якщо ви можете випадково написати:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

І раптом ваш метод завжди повертається foo.

Редагувати: це не в автоматичному форматуванні, а скоріше у стилі перевірки. Вибачте, якщо ця відповідь також була поза темою. :)

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

Ну, перевага такі ж , як будь-який код форматіровщік, як стандартизація коди, семантична між розробниками і т.д. Єдиний можливими недоліками , які я бачу , є відсутністю людського ока після того, як форматування, щоб додати деякі винятки, і т.д.
Так що я здогадуйтесь, краще розгляньте формат IDE замість форматера часу реєстрації.

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