Автоматический код форматирования

Наша команда недавно унаследовала код, который крайне дезорганизован.

В результате мой руководитель команды решил применить политику автоматического форматирования кода до сохранения файла. Мы даже нашли вариант в Eclipse (IDE по нашему выбору), который автоматически форматирует код перед каждым действием сохранения.

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

Каковы ваши мнения?

12 ответов

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


Я не согласен с вами. Для меня форматирование, даже если это всего лишь способ "представить" исходный код, также является важным индикатором качества кода.

Использование автоматического форматирования имеет несколько преимуществ. Он гомогенизирует формат среди всех разработчиков команды. Это позволит избежать некоторых проблем с манипуляцией SCM: например, слияние двух файлов, которые имеют мало реальных изменений, но много различий в форматировании - это кошмар!

Он также может показать вам некоторые ошибки. Например:

if (aCondition)
 foo();
 bar();

будет переформатирован:

if (condition)
 foo();
bar();

показывающий, что вторая строка не в операторе if.

Наконец, но не в последнюю очередь, хорошо отформатированный код (не только для Java) легче читать!


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

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


Я с вашим руководителем этой группы, и у меня есть два предложения для вас:

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

  • Согласиться со стандартом кодирования и настроить инструмент автоматического форматирования Eclipse следовать этому стандарту.


Согласованное форматирование кода действительно помогает с отличным и таким образом при отправке кода.

Я сконфигурировал сценарии исходного кода для автоматического форматирования в стиле "дом" при нажатии и авто-форматировании в соответствии с моим предпочтительным стилем при потянув, поэтому все счастливы.

Я бы порекомендовал вам рассмотреть то же самое.


Зависит от того, что вы подразумеваете под "дезорганизованным". Мы говорим о стилистических несоответствиях, или это классовая структура - непонятная мешанина? Я предполагаю, что первое, если вы обращаетесь к нему через автоформаттер.

"Правильное кодирование" не обязательно означает "согласованный между разработчиками". Если у меня есть мой редактор, установленный на четырехмерные жесткие вкладки, и у вас есть ваши трехмерные пробелы, код, с которым мы оба работаем, будет похож на задницу. (И наш менеджер проекта должен, вероятно, превзойти нас обоих вверх головой и сообщить нам, какой стандарт мы ДОЛЖНЫ использовать.)

Авто-форматирование - это немного грубого силового решения и в значительной степени гарантированно иногда превращает что-то необычное, но прекрасно читаемое в беспорядок. Если код на самом деле такой беспорядок, это разумная отправная точка. Но как только вы отформатировали основную часть Suck из ранее существовавшего кода, вам лучше создать предпочтительные соглашения о стиле команды и перейти оттуда.


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

Мы используем плагины, такие как checkstyle со стандартным набором правил, который должен соблюдаться, проверенный в коде не должен содержать никаких предупреждений о контроле. Если какой-то неструктурированный код приходит, форматер eclipse может сделать первую очистку и контрольный стиль, а друзья указывают на проблемы, оставшиеся до разрешения.


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

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


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

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

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

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

P.S. Последнее утверждение полностью анекдотично, поскольку у меня нет показателей для его резервного копирования.


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

При этом хорошо написанный код имеет решающее значение для написания надежного программного обеспечения.


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

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

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


Код форматирования чрезвычайно важен:

  • Сохраняя правильный код с отступом, для пользователя может быть проще навигация по средним или большим файлам.
  • Сохраняя постоянный стиль кодирования во всех проектах, когда люди переходят на другие проекты, они будут более знакомы с кодом. Конечно, это также связано с рекомендациями по кодированию, как назвать переменные и т.д., Которые также должны быть относительно нормализованы в общей среде.
  • Если вы потратите некоторое время на правильные правила форматирования кода, вы также гарантируете, что код может быть просмотрен другими пользователями (к сожалению, мне пришлось многократно редактировать код вручную в тексте [думаю, блокнот или emacs] вручную. Установив длину строки до 80 колод или около того, она может помочь)
  • Самое главное, сохраняя согласованность форматирования, вы можете значительно упростить два файла

licensed under cc by-sa 3.0 with attribution.