Wie deaktiviere ich den Eclipse-Code-Formatierer für bestimmte Abschnitte des Java-Codes?


488

Ich habe Java-Code mit SQL-Anweisungen, die als Java-Zeichenfolgen geschrieben sind (bitte keine OR / M-Flammen, das eingebettete SQL ist das, was es ist - nicht meine Entscheidung).

Ich habe die SQL-Anweisungen semantisch in mehrere verkettete Zeichenfolgen über mehrere Codezeilen aufgeteilt, um die Wartung zu vereinfachen. Also statt so etwas wie:

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

Ich habe so etwas wie:

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

Dieser Stil erleichtert das Lesen und Verwalten von SQL (IMHO) erheblich, insbesondere bei größeren Abfragen. Zum Beispiel kann ich meinen Editor in den "Überschreib" -Modus versetzen und den Text ziemlich einfach an Ort und Stelle ändern.

Beachten Sie, dass dieses Problem über das jeweilige Beispiel von SQL hinaus verallgemeinert wird. Jeder Code, der mit einer vertikalen Formatierung geschrieben wurde, insbesondere tabellarische Konstrukte, kann von einem hübschen Drucker zerstört werden.

Einige Projektmitglieder verwenden jetzt den Eclipse-Editor und die semantische Formatierung wird häufig zerstört, wenn sie eine gesamte Quelldatei formatieren.

Gibt es eine Möglichkeit, Eclipse anzuweisen, bestimmte Quellzeilen in Bezug auf die Formatierung zu ignorieren?

Ich suche nach einem speziellen Kommentar, der den Eclipse-Formatierer umschaltet. Im Idealfall kann ein solcher Kommentar so konfiguriert werden, dass er von uns ausgewählt wird, und andere Formatierer können so programmiert werden, dass er ihn ebenfalls berücksichtigt:

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

Eine "Lösung" besteht natürlich darin , unsere Teammitglieder auf einen externen Formatierer wie Jalopy oder JIndent standardisieren zu lassen , aber darum geht es bei dieser Frage nicht (auch nicht um meine Entscheidung für dieses Projekt): Ich suche speziell nach einem Weg zu Vermeiden Sie den Eclipse-Formatierer auf Ad-hoc-Basis.

Im Idealfall kann ich mit einer Lösung Anweisungen für den Eclipse-Formatierer einfügen, ohne dass Teammitglieder, die Eclipse verwenden, eine IDE-Neukonfiguration durchführen müssen (außer möglicherweise einen formatunabhängigen Befehlskommentar zu wählen: STOP-ECLIPSE-FORMATTINGSTOP-FORMATTING).


1
Wir haben dieses Problem gehabt. Eclipse sollte die Option haben, eine Zeile in einem String-Konstruktor mit einem + immer zu unterbrechen, unabhängig davon, ob das nächste Bit der Zeichenfolge in die Zeile passt. Aber das tut es nicht. :-(
JeeBee

Anscheinend wurde diese Funktion in Eclipse 3.6M6 hinzugefügt: bugs.eclipse.org/bugs/show_bug.cgi?id=27079
Guillaume

Hinweis: Wenn Sie lediglich verhindern möchten, dass Eclipse Ihre Kommentare durcheinander bringt, können Sie // vor jeder Zeile verwenden. Um einen Block zu kommentieren, markieren Sie und drücken Sie Strg + /.
John Henckel

Beachten Sie, dass Java 14 jetzt, 10 Jahre später, wahrscheinlich mehrzeilige Zeichenfolgen enthält, sodass dies der Vergangenheit angehört.
Thorbjørn Ravn Andersen

Antworten:


865

Mit Eclipse 3.6 können Sie die Formatierung deaktivieren, indem Sie einen speziellen Kommentar wie z

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

Die Ein / Aus-Funktionen müssen in den Eclipse-Einstellungen aktiviert sein : Java > Code Style > Formatter. Klicken Sie auf Edit, Off/On Tagsaktivieren Enable Off/On tags.

Es ist auch möglich, die magischen Zeichenfolgen in den Einstellungen zu ändern. Lesen Sie hier die Eclipse 3.6-Dokumente .

Mehr Informationen

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

Mit dieser Einstellung können Sie ein zu deaktivierendes Tag und ein Tag zum Aktivieren des Formatierers definieren (siehe Registerkarte Aus / Ein-Tags in Ihrem Formatierungsprofil):

Geben Sie hier die Bildbeschreibung ein

Sie müssen auch die Flags von aktivieren Java Formatting


7
Die Option "Niemals Linien verbinden", die an anderer Stelle auf dieser Seite erwähnt wird, ist ebenfalls sehr nützlich.
Xpmatteo

89
Die Ein / Aus-Funktionen müssen aktiviert sein. In den Eclipse-Einstellungen: Java> Codestil> Formatierer. Klicken Sie auf "Bearbeiten", "Aus / Ein-Tags" und aktivieren Sie "Aus / Ein-Tags aktivieren".
Domenic D.

2
Dies ist in den JavaScript-Codestileinstellungen nicht verfügbar , wo ich genau das gegenteilige Problem mit der Formatierung habe. :(
Redsandro

11
Teams sollten eine Kopie der Eclipse-Einstellungen (Datei) in ihr Wiki exportieren und von jedem verlangen, dass er dieselbe verwendet. Funktioniert gut für uns. ;)
Joseph Lust

Zu Ihrer Information, ich musste das Leerzeichen zwischen dem // und dem @ -Zeichen entfernen, damit dies funktioniert.
Roy Truelove

61

AFAIK von Eclipse 3.5 M4 im Formatierer verfügt über die Option "Niemals Zeilen verbinden", die die Zeilenumbrüche der Benutzer beibehält. Vielleicht macht das was du willst.

Sonst gibt es diesen hässlichen Hack

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

1
Also muss ich neben der Option "Niemals Linien verbinden" auch diese "Phantom" -Kommentare schreiben? Sollte der Teil "Never Join Lines" nicht von selbst funktionieren?
Greg Mattes

2
Ja, natürlich sollte es. Die Phantomkommentare sind ein alternativer Ansatz (falls sie nicht existieren oder Sie mit einer früheren Version usw. nicht weiterkommen).
Chris

Ich habe diesen Ansatz zusammen mit einer benutzerdefinierten Formatierungsvorlage in TOAD verwendet, damit ich das alte SQL aus dem JAVA-Code entfernen, neu formatieren und alle irrelevanten Kommentare abrufen und dann wieder in JAVA zurückwerfen kann. Es ist ein Schmerz, aber es erlaubt uns, beim Speichern unseres Java-Codes jetzt automatisch zu formatieren. Danke für den Vorschlag!
30.

Ohne die Option "Niemals Linien verbinden" zu aktivieren, funktionieren die Ein / Aus-Makros bei mir nicht - danke!
Christoffer Soop

28

Siehe diese Antwort auf SO .

Es gibt eine andere Lösung, mit der Sie die Formatierung bestimmter Blockkommentare unterdrücken können. Verwenden Sie /*-(beachten Sie den Bindestrich) am Anfang des Blockkommentars, und die Formatierung wird nicht beeinflusst, wenn Sie den Rest der Datei formatieren.

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

Quelle: Dokumentation bei Oracle .


2
Dies ist die beste Antwort, da dies nicht von der Konfiguration der IDE des Benutzers abhängt. Vielen Dank.
Azim

26

Anstatt die Formatierung zu deaktivieren, können Sie sie so konfigurieren, dass bereits umbrochene Zeilen nicht verbunden werden. Ähnlich wie bei Jitter, hier für Eclipse STS:

Eigenschaften → Java-Codestil → Formatierer → Projektspezifische Einstellungen aktivieren ODER Arbeitsbereichseinstellungen konfigurieren → Bearbeiten → Zeilenumbruch (Registerkarte) → Aktivieren Sie "Niemals bereits umbrochene Zeilen verbinden".

Speichern, anwenden.

Geben Sie hier die Bildbeschreibung ein


1
Ich denke, dies würde für Dinge wie das SQL-Beispiel helfen, aber ich bin nicht sicher, ob es für den allgemeinen Fall ausreichen würde, den IDE-Formatierer vollständig zu deaktivieren.
Greg Mattes

2
Diese Lösung eignet sich hervorragend für die Verwendung des Builder-Musters und ihre Relevanz wird mit der Einführung von Lambdas in Java 8 sicherlich erhöht.
Jonas Kongslund

16

Sie müssen die Möglichkeit aktivieren, die Formatierungs-Tags hinzuzufügen. In der Menüleiste gehen Sie zu:

Windows Preferences Java Code Style Formatter

Drücken Sie die EditTaste. Wählen Sie die letzte Registerkarte. Beachten Sie das Kontrollkästchen Ein / Aus und aktivieren Sie sie mit einem Kontrollkästchen.


14

Wenn Sie das Pluszeichen am Zeilenanfang einfügen, wird es anders formatiert:

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

1
Dies könnte ein interessanter Kompromiss sein. Im Allgemeinen möchte ich darauf verzichten, die Formatierung des Codes aufgrund eines unerwünschten Verhaltens eines Tools zu stark zu ändern. In diesem Fall sind die Zeichenfolgenverkettungsoperatoren eher ein Unfall als die Essenz dessen, was mit SQL vor sich geht. Deshalb schreibe ich sie lieber am Ende jeder Zeile. Ich bin der Meinung, dass SQL als Anfang der Zeile hervorgehoben werden sollte. Dies kann jedoch ein guter Weg sein, wenn keine Lösung vorhanden ist, mit der ich meine gewünschte Formatierung beibehalten kann. Vielen Dank!
Greg Mattes

8
Bitte. Eigentlich habe ich meine + Zeichen seit Jahrzehnten an die Spitze der Zeilen gesetzt, um den Formatierer nicht zu täuschen. Ich bevorzuge sie vorne, weil es mir klarer macht, was passiert: Was am Ende einer Zeile steht, geht manchmal verloren. Es war der Projektstandard vor einiger Zeit, als wir Holzverbrennungs-Compiler verwendeten, und er ist mir geblieben.
CPerkins

5

Ich verwende String-Teile mit fester Breite (mit Leerzeichen aufgefüllt), um zu vermeiden, dass der Formatierer meine SQL-String-Einrückung durcheinander bringt. Dies führt zu gemischten Ergebnissen und funktioniert nicht, wenn Leerzeichen nicht wie in SQL ignoriert werden, kann aber hilfreich sein.

    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                          ";

5

Beenden Sie jede Zeile mit einem doppelten Schrägstrich "//". Dadurch wird verhindert, dass die Sonnenfinsternis sie alle auf dieselbe Linie bewegt.


4

Alternative Methode: In Eclipse 3.6 gibt es unter "Zeilenumbruch" und dann "Allgemeine Einstellungen" die Option "Niemals bereits umbrochene Zeilen verbinden". Dies bedeutet, dass der Formatierer lange Zeilen umbricht, aber bereits vorhandene Umbrüche nicht rückgängig macht.


4

@xpmatteo hat die Antwort auf das Deaktivieren von Codeteilen. Darüber hinaus sollten die Standardeinstellungen für Eclipse so eingestellt werden, dass nur bearbeitete Codezeilen anstelle der gesamten Datei formatiert werden.

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

Dies hätte verhindert, dass dies überhaupt passiert, da Ihre Mitarbeiter Code neu formatieren, den sie nicht wirklich geändert haben. Dies ist eine gute Vorgehensweise, um Pannen zu vermeiden, die Unterschiede in Ihrer Quellcodeverwaltung unbrauchbar machen (wenn eine gesamte Datei aufgrund geringfügiger Unterschiede bei den Formateinstellungen neu formatiert wird).

Es würde auch die Neuformatierung verhindern, wenn die Option Ein / Aus-Tags deaktiviert wäre.


2

Die Phantomkommentare, die hinzufügen, //wo Sie neue Zeilen möchten, sind großartig!

  1. Mit @formatter: off wird dem Editor eine Referenz aus dem Code hinzugefügt. Der Code sollte meiner Meinung nach niemals solche Verweise haben.

  2. Die Phantomkommentare (//) funktionieren unabhängig vom verwendeten Formatierungswerkzeug. Unabhängig von Eclipse oder InteliJ oder dem von Ihnen verwendeten Editor. Dies funktioniert sogar mit dem sehr schönen Google Java-Format

  3. Die Phantomkommentare (//) funktionieren in Ihrer gesamten Anwendung. Wenn Sie auch Javascript haben und vielleicht so etwas wie JSBeautifier verwenden . Sie können einen ähnlichen Codestil auch in Javascript verwenden.

  4. Eigentlich möchten Sie wahrscheinlich richtig formatieren ? Sie möchten gemischte Tabulatoren / Leerzeichen und nachfolgende Leerzeichen entfernen. Sie möchten die Zeilen gemäß dem Codestandard einrücken. Was Sie nicht wollen, ist eine lange Schlange. Das und nur das gibt dir der Phantomkommentar!


-3

Dieser Hack funktioniert:

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

Ich würde vorschlagen, den Formatierer nicht zu verwenden. Schlechter Code sollte schlecht aussehen, nicht künstlich gut. Guter Code braucht Zeit. Qualität kann man nicht betrügen. Die Formatierung ist Teil der Quellcodequalität.


8
Es ist nur eine schlechte Idee, den Formatierer nicht zu verwenden. Der Formatierer hilft, Fehler zu erkennen, und hält den Code in einem konsistenten Zustand.
Francis Upton IV

Ein interessanter Vorschlag, aber ich sehe nicht, wie die Formatierung uns sagt, ob Code gut ist oder nicht.
Chris

2
Ich denke, was er sagt, ist, dass er der Meinung ist, dass schlecht geschriebener, schlecht formatierter Code unverändert bleiben sollte, anstatt ihn in der Hoffnung zu formatieren, "ihn zu verbessern". Schlecht geschriebener, schlecht formatierter Code sollte irgendwie "herausragen", damit er leicht identifiziert werden kann. Ich bin mir nicht ganz sicher, ob ich damit einverstanden bin, aber ich denke, das ist die Idee.
Greg Mattes

1
@Francis - Fehler: Wie können automatisch formatierte Code-Fehler gefunden werden? Konsistenz: Konsistenz ist ein gutes Argument, aber die allgemeine Codequalität ist wichtiger. Sie können einen schönen konsistenten Prozess für das Umdrehen von Hamburger definieren, der jedoch für die Haute Cuisine niemals funktioniert. Das Kochen von a kann eine ziemlich komplizierte oder triviale Aktivität sein, wenn Sie genügend Fakten ignorieren. Wenn Sie der Meinung sind, dass Softwareentwicklung wie Hamburger-Flip-Tools ist, die die Konsistenz erzwingen, sind Sie hier richtig. Dies ist kein Argument gegen die Formatierung von Richtlinien, aber wenn sich die Entwickler nicht um diese Richtlinien kümmern, kümmern sie sich nicht um andere wichtige Elemente.
Thomas Jung

4
Mein Argument hier: Ich schreibe guten Code und halte mich an die Formatierungsrichtlinien. Aber ich bin faul. Warum sollte ich die richtige Anzahl von Leerzeichen und Zeilenumbrüchen einfügen müssen, wenn ich meine fünf Zeilen schlampigen Codes schreiben, die Format-Taste drücken und glücklich sein kann? Nachdem ich den Code mit meinem Tool formatiert habe, das sicherstellt, dass das Ergebnis immer perfekt ist, bin ich in Bezug auf die Formatierung genauso nazistisch wie jeder andere. Es gibt KEIN Argument gegen das Festhalten an den Richtlinien (außer dass sie besonders schlecht sein können), wenn die Formatierung nur einen Kestroke entfernt ist. Alle Projektmitglieder verwenden dieselben Codeformatierungseinstellungen.
Per Wiklander
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.