Код автоматического форматирования

Question

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

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

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

Ваше мнение?

Answer 1

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

Answer 2

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

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

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

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

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

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

показывает, что вторая линия не в if заявлении.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

Answer 9

Форматирование кода является чрезвычайно важным:

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

Answer 10

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

1. Сохранить каждый файл один раз, где только изменения форматирования с сообщения фиксации, которое отражает, что это все, что изменилось, в n перейти назад и сделать свой фактический код изменений. Это сэкономит вам много времени времени, когда вам нужно разбить изменений. В редакторе формата будет , почти каждая строка кода изменена, поэтому практически невозможно найти реальное изменение на той же ревизии.

2. Согласитесь со стандартом кодирования и настройте инструмент автоматического форматирования Eclipse , чтобы следовать этому стандарту.

Answer 11

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

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

Answer 12

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

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

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