Как отключить форматирование кода Eclipse для определенных разделов кода Java?

416

У меня есть Java-код с операторами SQL, написанными как строки Java (пожалуйста, нет OR/M flamewars, встроенный SQL - это то, что есть, а не мое решение).

Я разделил SQL-запросы семантически на несколько конкатенированных строк на несколько строк кода для удобства обслуживания. Поэтому вместо чего-то вроде:

String query = "SELECT FOO, BAR, BAZ FROM ABC WHERE BAR > 4";

У меня есть что-то вроде:

String query =
    "SELECT FOO, BAR, BAZ" +
    "  FROM ABC          " +
    " WHERE BAR > 4      ";

Этот стиль упрощает чтение и обслуживание SQL (IMHO), особенно для больших запросов. Например, я могу поместить мой редактор в режим "перезаписывания" и довольно легко изменить текст на месте.

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

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

Есть ли способ проинструктировать Eclipse игнорировать некоторые строки источника в отношении форматирования?

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

// STOP-ECLIPSE-FORMATTING
String query =
    "SELECT FOO, BAR, BAZ" +
    "  FROM ABC          " +
    " WHERE BAR > 4      ";
// START-ECLIPSE-FORMATTING

Очевидно, что одно "решение" состоит в том, чтобы наши члены команды стандартизировали какой-то внешний форматтер, например Jalopy или JIndent, но это не то, о чем этот вопрос (а также не мое решение по этому проекту): я специально ищу способ избежать форматирования Eclipse ad-hoc.

В идеале, решение позволит мне вставлять инструкции для форматирования Eclipse , не требуя от членов команды, использующих Eclipse, выполнять любую реконфигурацию IDE (кроме, возможно, выбора комментария команды агностики formatter: STOP-ECLIPSE-FORMATTINGSTOP-FORMATTING).

  • 1
    У нас была эта проблема. Eclipse должен иметь возможность всегда разрывать строку в конструкторе String, где находится +, независимо от того, поместится ли следующий бит строки в строку. Но это не так. :-(
  • 0
    Очевидно, эта функция была добавлена в Eclipse 3.6M6: bugs.eclipse.org/bugs/show_bug.cgi?id=27079.
Показать ещё 1 комментарий
Теги:
pretty-print
code-formatting
eclipse-formatter

12 ответов

825
Лучший ответ

Eclipse 3.6 позволяет отключить форматирование, разместив специальный комментарий, например

// @formatter:off
...
// @formatter:on

Функции включения/выключения должны быть повернуты "on" в настройках Eclipse: Java > Code Style > Formatter. Нажмите Edit, Off/On Tags, включите Enable Off/On tags.

Также возможно изменить магические строки в настройках - проверить здесь документы Eclipse 3.6.

Дополнительная информация

Java > Code Style > Formatter > Edit > Off/On Tags

Это предпочтение позволяет определить один тег для отключения и один тег для включения форматирования (см. вкладку "Выкл./Вкл. теги" в вашем профиле форматирования):

Изображение 1526

Вам также нужно включить флаги с Java Formatting

  • 7
    Опция «Никогда не соединять линии», которая упоминается в других разделах этой страницы, также очень полезна.
  • 86
    Функции включения / выключения должны быть включены. В настройках Eclipse: Java> Стиль кода> Форматировщик. Нажмите кнопку «Редактировать», «Выкл. / Вкл. Теги», отметьте «Включить теги Выкл. / Вкл.».
Показать ещё 6 комментариев
55

AFAIK от Eclipse 3.5 M4 на форматировании имеет опцию "Never Join Lines", которая сохраняет разрывы пользовательских строк. Возможно, это делает то, что вы хотите.

Иначе есть этот уродливый хак

String query = //
    "SELECT FOO, BAR, BAZ" + //
    "  FROM ABC"           + //
    " WHERE BAR > 4";
  • 1
    Так что в дополнение к настройке опции «Никогда не присоединяться к линиям» я также должен написать эти «фантомные» комментарии? Разве часть «Никогда не соединяй линии» не должна работать сама по себе?
  • 2
    Да, конечно, это должно быть. Фантомные комментарии являются альтернативным подходом (в случае, если он не существует, или вы застряли с более ранней версией и т. Д.).
Показать ещё 2 комментария
23

Вместо того, чтобы отключить форматирование, вы можете настроить его, чтобы не присоединить уже завернутые строки. Подобно ответу Джиттера, здесь для Eclipse STS:

Свойства → Стиль Java-кода → Formatter → Включить специальные настройки проекта ИЛИ Настроить параметры рабочей области → Изменить → Линейная упаковка (вкладка) → установите флажок "Никогда не присоединяйте уже завернутые строки"

Сохранить, применить.

Изображение 1527

  • 1
    Я думаю, что это поможет для таких вещей, как пример SQL, но я не уверен, что этого будет достаточно для общего случая полного отключения средства форматирования IDE.
  • 1
    Это решение отлично подходит для использования шаблона компоновщика, и его актуальность, безусловно, возрастает с введением лямбда-выражений в Java 8.
18

Смотрите этот ответ на SO.

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

/*-
 * Here is a block comment with some very special
 * formatting that I want indent(1) to ignore.
 *
 *    one
 *        two
 *            three
 */

Источник: Документация в Oracle.

  • 2
    Это лучший ответ, так как он не зависит от конфигурации IDE пользователя. Благодарю.
16

Вам нужно включить возможность добавления тегов форматирования. В строке меню:

Windows Preferences Java Code Style Formatter

Нажмите кнопку Edit. Выберите последнюю вкладку. Обратите внимание на поле "Вкл./Выкл." И включите их с помощью флажка.

14

Если вы положите знак "плюс" в начале строки, он форматирует по-разному:

String query = 
    "SELECT FOO, BAR, BAZ" 
    +    "  FROM ABC"           
    +    " WHERE BAR > 4";
  • 1
    Это может быть интересным компромиссом. В целом, я хотел бы воздержаться от слишком большого изменения форматирования кода из-за нежелательного поведения одного инструмента. В этом случае операторы конкатенации строк являются скорее случайностью, а не сущностью того, что происходит с SQL. Вот почему я предпочитаю писать их в конце каждой строки. Я чувствую, что SQL должен быть выделен как начало строки. Но это может быть хорошим путем, если нет решения, которое позволило бы мне сохранить желаемое форматирование. Спасибо!
  • 7
    Пожалуйста. На самом деле, я десятилетиями ставил свои знаки + на передний план, чтобы не обманывать средство форматирования. Я предпочитаю их на фронте, потому что мне становится понятнее, что происходит в конце строки, иногда теряется. Когда-то, когда мы использовали дровяные компиляторы, это был стандарт проекта, и он застрял у меня.
5

Завершите каждую из строк двойной косой чертой "//". Это заставило бы затмение перемещать их все в одну строку.

5

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

    final String sql = "SELECT v.value FROM properties p               "
            + "JOIN property_values v ON p.property_id = v.property_id "
            + "WHERE p.product_id = ?                                  "
            + "AND v.value        IS NOT NULL                          ";
4

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

Preferences->Java->Editor->Save Actions->Format Source Code->Format Edited Lines

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

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

4

Альтернативный метод: в Eclipse 3.6 в разделе "Линейная упаковка" затем "Общие настройки" есть опция "Никогда не присоединяться к уже завернутым строкам". Это означает, что форматировщик будет обертывать длинные строки, но не отменяет какую-либо упаковку, которую вы уже имеете.

0

Фантомные комментарии, добавляющие // где вы хотите новые строки, великолепны!

  1. @Formatter: off добавляет ссылку из кода в редактор. Кодекс должен, на мой взгляд, никогда не иметь таких ссылок.

  2. Фантомные комментарии (//) будут работать независимо от используемого инструмента форматирования. Независимо от Eclipse или InteliJ или любого другого редактора, который вы используете. Это даже работает с очень приятным форматом Google Java

  3. Фантомные комментарии (//) будут работать по всему вашему приложению. Если у вас также есть Javascript и, возможно, используйте что-то вроде JSBeautifier. Аналогичный стиль кода можно также использовать в Javascript.

  4. На самом деле, вы, вероятно, хотите правильно форматировать? Вы хотите удалить смешанные пробелы и пробелы. Вы хотите отступать по строкам в соответствии со стандартом кода. То, что вы НЕ хотите, это длинная линия. Это и только то, что дает вам фантомный комментарий!

-4

Этот хак работает:

String x = "s" + //Formatter Hack
    "a" + //
    "c" + //
    "d";

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

  • 8
    Не использовать форматтер - это просто плохая идея; средство форматирования помогает отлавливать ошибки и поддерживает код в согласованном состоянии.
  • 0
    Интересное предложение, но я не вижу, как форматирование говорит нам, хорош ли код или нет.
Показать ещё 6 комментариев
Сообщество Overcoder
Наверх
Меню