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


20

Я использую Eclipse для кодирования, и язык, который мы используем, - Java. Однажды кому-то было предложено правильно отформатировать код, используя автоформатер (CTRL + SHIFT + F). Хотя эта команда форматирует код, но иногда я чувствую, что общий вид становится странным, и на самом деле он не очень читабелен.

Так это рекомендуемая вещь? Если нет, то что лучше форматировать наш код в Eclipse?


Я все время использую возможности emacs для автоформатирования - есть потенциальные возможности для коллизий (например, со слиянием SC) ... но в целом стандартизация вашего формата чрезвычайно полезна
warren

Ответы:


34

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

Eclipse (или любая хорошая IDE в этом отношении) имеет правила форматирования кода, которые можно настроить в разделе настроек (Java> Code Style> Formatter). Выберите то, что вам нравится больше всего, но взгляните также на стандартные соглашения по коду Java . Многие проекты с открытым исходным кодом также имеют свои собственные соглашения по коду, которые можно применять с помощью форматера Eclipse.

Кроме того, существуют стандартные инструменты, такие как CodeStyle, PMD и Findbugs, которые обеспечивают выполнение дополнительных правил и помогают избежать распространенных (низкоуровневых) антишаблонов и ошибок.


4
После того, как вы настроили ваш форматтер так, как вам хотелось бы. Есть кнопка «Экспорт», которая позволит вам сохранить ее в XML-файл. Мы поместили это в наш SVN-репозиторий, чтобы каждый мог получить к нему доступ, когда они проверят проект.
Крис

Я согласен с этим и использую PMD и FindBugs и все. Но это хорошая идея, если все в команде следуют и используют правила форматирования кода. В противном случае вы получите коммиты, которые являются изменениями + форматированием одних разработчиков, а не других, и трудно увидеть «реальные» изменения. Другими словами, если старый код еще не отформатирован с помощью автоматического форматирования, не форматируйте его с дополнительными изменениями в одном коммите.
Муфаса

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

24

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

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

Но да, иногда автоформатор портит какую-то красиво отформатированную таблицу. В таких случаях я использую «вкл / выкл теги». Они настраиваются на вкладке «Теги включения / выключения» в профиле форматирования кода. Используя их, вы можете исключить регионы в вашем коде из автоматического форматирования:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

5
+1: я никогда не знал о (или, если быть более точным, я никогда не удосужился узнать о) тегах включения / выключения.
Пол Кейджер

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

@Mufasa Да, ты прав.
JesperE

1
Если вы не хотите форматировать комментарий, вы можете написать / * - мой суперформат * / Eclipse не форматирует такой комментарий :)
Дэвид Дрозд

5

Будет ли это рекомендовано, зависит от того, кого вы спросите.

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

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

Хорошая IDE или инструмент часто могут выполнять приличную работу по форматированию кода для вас, но не всегда делают его читаемым, как вы могли бы.

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


5

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

Форматировщик Java в Eclipse делает довольно хорошую работу и полностью настраивается. Если вы не согласны с настройками по умолчанию (которые я полностью понимаю), то вам следует настроить форматер в соответствии с вашими личными предпочтениями стиля или того стандарта, который вы используете. Вы можете сделать это в настройках под Java / Code Style / Formatter.

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


0

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

В частности, если у вас включены «очистка кода» + «форматтер», отступы фиксируются / не фиксируются при каждом сохранении.

Каждая новая версия Eclipse может изменять форматер (в лучшую сторону), но вносит значительные изменения, такие как JavaDocs, наконец, удаляя это дополнительное пространство после, *но появившийся спустя некоторое время после того, как Helios и многие предприятия используют более старую версию Eclipse для Rational Software. который использует Гелиос в качестве базы.

Средство форматирования кода, предоставляемое Eclipse, не расширяемо для их API, фактически оно явно заявляет javadoc CodeFormatter

Этот класс не предназначен для использования в подклассах клиентами.

Конечно, я пока не нашел жизнеспособной некоммерческой альтернативы. Jalopy не обновлялась уже много лет, и вилы в github еще не организованы, чтобы я рекомендовал какой-либо из них. Также у него нет сайта обновлений для Eclipse для его интеграции. На самом деле я планировал сделать форматирование кода как часть сборки так же, как я делал cleanpom-maven-plugin с использованием Jalopy, но эта идея отошла на второй план из-за отсутствия обновлений для Jalopy.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.