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

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

Я думаю, что это очень важно сделать. Вот почему:

• Это делает ваши различия в управлении исходным кодом только фактическими изменениями кода, и почти исключает "шум шума" из-за пробелов и других незначительных вариантов форматирования
• Это делает весь код более похожим, так что разработчикам удобнее создавать пары и делиться базами кода

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

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

Я собираюсь бросить свой собственный ответ здесь, поскольку люди только, кажется, добавляют преимущества. Что я вижу в качестве недостатков:

• Исключает возможность делать «лучше», чем автоформатер ... это отменит ваше более чистое форматирование. Примером этого могут быть объявления параметров на основе столбцов, списки отдельных добавлений объектов и т. Д.
• Создает сопротивление изменяющемуся стилевому соглашению, поскольку теперь это приведет к большим ошибочным изменениям различий.
• Удаляет возможность выполнять любое специальное форматирование, когда альтернативный формат делает код более читабельным.
• Он связывает вас с использованием IDE, которые поддерживают именно те функции переформатирования, которые вам нужны. В другой IDE отсутствует одна из необходимых вам опций, это вызовет как минимум некоторые проблемы.
• Совместное использование репозитория записываемого кода с внешней группой становится проблематичным, если только они не используют те же соглашения о формате, что и ваша группа (как правило, так и будет, но не всегда).
• Всегда будут исключения, когда немного другой формат, вероятно, чище, чем предписанный стиль. Таким образом, автоконвертация может часто скрывать намерения определенных блоков кода, что практически так же хорошо, как добавление дефекта в код.

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

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

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

Основным недостатком является потеря пользовательского форматирования там, где это действительно важно.

Представьте себе типичную проверку работоспособности if (), которая завершится неудачей, если какое-либо из определенных условий присутствует, но не выполнено ...

  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 () должны следовать фигурные скобки, так как это довольно легко получить, если вы ошибаетесь, если вы выполняете рефакторинг.

Рассмотрим этот случай:

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

Если вы сейчас хотите добавить запись в регистр if, вы можете написать случайно:

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

И вдруг ваш метод всегда возвращается foo.

Редактировать: это не автоматическое форматирование, а проверка стиля. Извините, если этот ответ был также не по теме. :)

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

Ну, преимущества такие же, как у любого средства форматирования кода, такие как стандартизация кода, семантика между разработчиками и т. Д. Единственные возможные недостатки, которые я вижу, это отсутствие человеческого глаза после форматирования, чтобы добавить некоторые исключения и т. Д.
Итак, я думаю, лучше рассмотреть форматировщик IDE вместо форматера времени регистрации.

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