Jak wyłączyć formatyzator kodu Eclipse dla niektórych sekcji kodu Java?

488

Mam trochę kodu Java z instrukcjami SQL zapisanymi jako ciągi Java (proszę nie flamewars OR / M, osadzony SQL jest tym, czym jest - nie moja decyzja).

Podzieliłem semantycznie instrukcje SQL na kilka połączonych łańcuchów w kilku wierszach kodu, aby ułatwić obsługę. Zamiast czegoś takiego:

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

Mam coś takiego:

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

Ten styl znacznie ułatwia czytanie i utrzymywanie kodu SQL (IMHO), szczególnie w przypadku większych zapytań. Na przykład mogę wprowadzić mój edytor w tryb „nadpisywania” i dość łatwo modyfikować tekst w miejscu.

Zauważ, że problem ten generalnie wykracza poza konkretny przykład SQL. Każdy kod napisany z dowolnym formatowaniem pionowym, szczególnie w konstrukcjach tabelarycznych, może zostać zniszczony przez ładną drukarkę.

Teraz niektórzy członkowie projektu używają edytora Eclipse, a formatowanie semantyczne jest często niszczone, gdy formatują cały plik źródłowy.

Czy istnieje sposób, aby poinstruować środowisko Eclipse, aby ignorowało pewne wiersze źródła w odniesieniu do formatowania?

Szukam czegoś w rodzaju specjalnego komentarza, który przełącza formatyzator Eclipse. Idealnie, taki komentarz mógłby być konfigurowalny, aby był tym, co wybieramy, a inne formaterery mogłyby być zaprogramowane tak, aby szanowały go:

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

Oczywiście, jeden „rozwiązanie” jest, aby nasi członkowie zespołu standaryzacji na jakimś zewnętrznym formater jak gruchot lub JIndent , ale to nie to co to pytanie jest o (również nie moja decyzja w sprawie tego projektu): Ja specjalnie szuka sposobu na unikaj formatyzatora Eclipse na zasadzie ad hoc.

Idealnie, rozwiązanie pozwoli mi na wstawienie instrukcji dla formatera Eclipse bez wymagania od członków zespołu używającego Eclipse wykonania jakiejkolwiek rekonfiguracji IDE (oprócz możliwości wybrania komentarza agnostycznego formatera: STOP-ECLIPSE-FORMATTINGSTOP-FORMATTING).

Greg Mattes
źródło
1
Mieliśmy ten problem. Zaćmienie powinno mieć opcję, aby zawsze przerywać linię w konstruktorze ciągu, w którym znajduje się znak +, niezależnie od tego, czy następny bit ciągu będzie pasował do linii. Ale tak nie jest. :-(
JeeBee
Najwyraźniej ta funkcja została dodana w Eclipse 3.6M6: bugs.eclipse.org/bugs/show_bug.cgi?id=27079
Guillaume
Uwaga: jeśli chcesz po prostu zapobiec zepsuciu komentarzy przez zaćmienie, możesz użyć // przed każdą linią. Aby skomentować blok, zaznacz i naciśnij Ctrl + /.
John Henckel,
Zauważ, że teraz 10 lat później Java 14 prawdopodobnie przyniesie ciągi wieloliniowe, dzięki czemu to już przeszłość.
Thorbjørn Ravn Andersen

Odpowiedzi:

865

Eclipse 3.6 pozwala wyłączyć formatowanie poprzez umieszczenie specjalnego komentarza, np

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

ON / OFF funkcje muszą być włączone „na” w preferencjach Eclipse: Java > Code Style > Formatter. Kliknij Edit, Off/On Tagswłącz Enable Off/On tags.

Można także zmienić magiczne ciągi w preferencjach - zapoznaj się z dokumentacją Eclipse 3.6 tutaj .

Więcej informacji

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

Ta preferencja pozwala zdefiniować jeden znacznik do wyłączenia i jeden znacznik do włączenia formatyzatora (zobacz zakładkę Wyłącz / Włącz znaczniki w profilu formatyzatora):

wprowadź opis zdjęcia tutaj

Musisz także włączyć flagi z Java Formatting

xpmatteo
źródło
7
Bardzo przydatna jest również opcja „Nigdy nie łącz linii”, która jest wspomniana w innym miejscu na tej stronie.
xpmatteo
89
Funkcje włączania / wyłączania muszą być włączone. W preferencjach Eclipse: Java> Styl kodu> Formatyzator. Kliknij przycisk „Edytuj”, „Wyłączone / Włączone tagi”, zaznacz „Włącz wyłączone / Włączone tagi”.
Domenic D.,
2
Nie jest to dostępne w preferencjach Stylu kodu JavaScript , gdzie mam dokładnie odwrotny problem z formatowaniem. :(
Redsandro
11
Zespoły powinny wyeksportować kopię preferencji (pliku) Eclipse na swoje wiki i wymagać od wszystkich korzystania z tego samego. Działa dla nas dobrze. ;)
Joseph Lust
Do Twojej wiadomości musiałem usunąć spację między znakiem // a znakiem @, aby to zadziałało.
Roy Truelove
61

AFAIK z Eclipse 3.5 M4 na formatyzatorze ma opcję „Nigdy nie łącz linii”, która zachowuje podział linii użytkownika. Może to robi co chcesz.

W przeciwnym razie jest ten brzydki hack

String query = //
    "SELECT FOO, BAR, BAZ" + //
    "  FROM ABC"           + //
    " WHERE BAR > 4";
drganie
źródło
1
Więc oprócz ustawienia opcji „Nigdy nie dołączaj do linii” muszę również napisać te „fantomowe” komentarze? Czy część „Never Join Lines” nie powinna sama działać?
Greg Mattes
2
Tak, oczywiście, że powinno. Komentarze fantomowe są alternatywnym podejściem (na wypadek, gdyby nie istniały lub utknąłeś z wcześniejszą wersją itp.).
Chris
Użyłem tego podejścia w połączeniu z niestandardowym szablonem formatowania w TOAD, aby umożliwić mi usunięcie starego kodu SQL z kodu JAVA, sformatowanie go i pobranie wszystkich obcych komentarzy, a następnie wrzucenie go z powrotem do JAVA. Jest to uciążliwe, ale teraz możemy automatycznie formatować przy zapisywaniu naszego kodu Java. Dzieki za sugestie!
jnt30
Bez zaznaczenia „Nigdy nie łącz linii” makra on / off nie działają dla mnie - dzięki!
Christoffer Soop,
28

Zobacz tę odpowiedź na SO .

Istnieje inne rozwiązanie, którego można użyć, aby ukryć formatowanie określonych komentarzy do bloku. Użyj /*-(zwróć uwagę na myślnik) na początku komentarza do bloku, a formatowanie nie zmieni się, jeśli sformatujesz resztę pliku.

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

Źródło: Dokumentacja w Oracle .

Renaud
źródło
2
To najlepsza odpowiedź, ponieważ nie zależy od konfiguracji IDE użytkownika. Dzięki.
Azim
26

Zamiast wyłączać formatowanie, możesz go skonfigurować tak, aby nie dołączał już zawiniętych linii. Podobnie do odpowiedzi Jittera, oto Eclipse STS:

Właściwości → Styl kodu Java → Formatyzator → Włącz ustawienia specyficzne dla projektu LUB Skonfiguruj Ustawienia obszaru roboczego → Edytuj → Zawijanie linii (karta) → zaznacz „Nigdy nie dołączaj już zawiniętych linii”

Zapisz, zastosuj.

wprowadź opis zdjęcia tutaj

ilinca
źródło
1
Myślę, że pomogłoby to w przypadku przykładu SQL, ale nie jestem pewien, czy wystarczyłoby to w ogólnym przypadku całkowitego wyłączenia formatera IDE.
Greg Mattes
2
To rozwiązanie jest doskonałe, gdy używa się wzorca konstruktora, a jego znaczenie z pewnością zwiększa się wraz z wprowadzeniem lambdas w Javie 8.
Jonas Kongslund
16

Musisz włączyć możliwość dodawania tagów formatera. W pasku menu przejdź do:

Windows Preferences Java Code Style Formatter

Naciśnij Editprzycisk. Wybierz ostatnią kartę. Zwróć uwagę na pole On / Off i włącz je za pomocą pola wyboru.

ZilWerks
źródło
14

Jeśli umieścisz znak plus na początku wiersza, formatuje się inaczej:

String query = 
    "SELECT FOO, BAR, BAZ" 
    +    "  FROM ABC"           
    +    " WHERE BAR > 4";
CPerkins
źródło
1
To może być interesujący kompromis. Ogólnie rzecz biorąc, chciałbym powstrzymać się od zbytniej zmiany formatowania kodu z powodu niepożądanych działań jednego narzędzia. W tym przypadku operatory konkatenacji ciągów są raczej wypadkiem niż istotą tego, co dzieje się z SQL. Dlatego wolę je pisać na końcu każdej linii. Uważam, że SQL powinien być podkreślony jako początek linii. Ale może to być dobry sposób na brak rozwiązania, które pozwala mi zachować pożądane formatowanie. Dzięki!
Greg Mattes
8
Nie ma za co. Właściwie od dziesięcioleci stawiam moje znaki + na pierwszym planie linii i nie oszukuję formatyzatora. Wolę je z przodu, ponieważ sprawia, że ​​to, co się dzieje, jest dla mnie wyraźniejsze: to, co na końcu linii czasami się gubi. Kiedyś używaliśmy kompilatorów do wypalania drewna, było to kiedyś standardem projektu i utknęło we mnie.
CPerkins,
5

Używam części ciągów o stałej szerokości (wypełnionych białymi spacjami), aby uniknąć sytuacji, w której formatyzator zepsułby moje wcięcie ciągu SQL. Daje to mieszane wyniki i nie działa, gdy białe znaki nie są ignorowane, jak w SQL, ale mogą być pomocne.

    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                          ";
Guus
źródło
5

Zakończ każdą linię podwójnym ukośnikiem „//”. To powstrzyma zaćmienie przed przeniesieniem ich wszystkich na tę samą linię.

Evvo
źródło
4

Alternatywna metoda: w Eclipse 3.6, w „Zawijaniu linii”, a następnie „Ustawieniach ogólnych” dostępna jest opcja „Nigdy nie łącz już zawiniętych linii”. Oznacza to, że formatyzator zawinie długie linie, ale nie cofnie żadnego już zawinięcia.

kmccoy
źródło
4

@xpmatteo ma odpowiedź na wyłączenie części kodu, ale oprócz tego domyślne ustawienia zaćmienia powinny być ustawione na formatowanie tylko edytowanych wierszy kodu zamiast całego pliku.

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

Zapobiegałoby to przede wszystkim temu, ponieważ Twoi współpracownicy przeformatowali kod, którego tak naprawdę nie zmienili. Jest to dobra praktyka, aby zapobiegać wpadkom, które sprawiają, że diff w kontroli źródła jest bezużyteczny (kiedy formatowany jest cały plik z powodu niewielkich różnic w ustawieniach formatu).

Uniemożliwiłoby to również ponowne formatowanie, gdyby opcja znaczników on / off była wyłączona.

Rudzik
źródło
2

Widmowe komentarze, dodając //gdzie chcesz nowe linie, są świetne!

  1. @Formatter: off dodaje odniesienie z kodu do edytora. Moim zdaniem kod nigdy nie powinien zawierać takich odniesień.

  2. Komentarze fantomowe (//) będą działać niezależnie od użytego narzędzia formatowania. Niezależnie od Eclipse lub InteliJ lub dowolnego edytora, którego używasz. Działa to nawet z bardzo ładnym formatem Google Java

  3. Komentarze fantomowe (//) będą działać w całej aplikacji. Jeśli masz także JavaScript i być może używasz czegoś takiego jak JSBeautifier . Możesz mieć podobny styl kodu także w JavaScript.

  4. Właściwie prawdopodobnie chcesz formatować, prawda? Chcesz usunąć mieszane tabulatory / spacje i końcowe spacje. Chcesz wciąć wiersze zgodnie ze standardem kodu. To czego NIE chcesz, to długa linia. I to tylko to, co daje ci fantomowy komentarz!

Tomas Bjerre
źródło
-3

Ten hack działa:

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

Sugerowałbym, aby nie używać formatyzatora. Zły kod powinien wyglądać źle, a nie sztucznie dobry. Dobry kod wymaga czasu. Nie możesz oszukiwać jakości. Formatowanie jest częścią jakości kodu źródłowego.

Thomas Jung
źródło
8
Nieużywanie formatera to po prostu zły pomysł; formatyzator pomaga wychwytywać błędy i utrzymuje kod w spójnym stanie.
Francis Upton IV,
Ciekawa propozycja, ale nie widzę, jak formatowanie mówi nam, czy kod jest dobry, czy nie.
Chris
2
Myślę, że to, co mówi, to to, że uważa, że ​​źle napisany, źle sformatowany kod powinien być przechowywany w niezmienionej formie, a nie formatować go w nadziei na „poprawę”. Źle napisany, źle sformatowany kod powinien jakoś „wystawać”, aby można go było łatwo zidentyfikować. Nie jestem pewien, czy całkowicie się zgadzam, ale myślę, że taki jest pomysł.
Greg Mattes
1
@Francis - Bugs: Jak można automatycznie formatować błędy w wyszukiwaniu kodu? Spójność: Spójność jest dobrym argumentem, ale ogólna jakość kodu jest ważniejsza. Możesz zdefiniować ładny, spójny proces rzutowania hamburgerów, ale nigdy nie zadziała w przypadku haute cuisine. Gotowanie może być dość skomplikowaną czynnością lub trywialne, jeśli zignorujesz wystarczającą liczbę faktów. Jeśli uważasz, że tworzenie oprogramowania przypomina narzędzia do rzucania hamburgerów, wymuszanie spójności jest dla Ciebie. Nie jest to argumentem przeciwko formatowaniu linii pomocniczych, ale jeśli programiści nie przejmują się tymi wytycznymi, nie przejmą się innymi niezbędnymi sprawami.
Thomas Jung,
4
Mój argument tutaj: piszę dobry kod i trzymam się linii przewodnich formatowania. Ale jestem LAZY. Dlaczego powinienem wstawiać odpowiednią liczbę spacji i podziałów wierszy, skoro mogę napisać pięć wierszy niechlujnego kodu, nacisnąć przycisk formatowania i być szczęśliwym? PO sformatowaniu kodu za pomocą mojego narzędzia, które zapewnia, że ​​wynik jest zawsze idealny, jestem tak nazistowski jak wszyscy w kwestii formatowania. Nie ma ŻADNEGO argumentu przeciwko przyklejaniu się do linii prowadzących (inne, że mogą być szczególnie złe), jeśli formatowanie jest tylko jednym krokiem. Wszyscy członkowie projektu mają takie same ustawienia formatowania kodu.
Per Wiklander