Comment désactiver le formateur de code Eclipse pour certaines sections de code Java?


489

J'ai du code Java avec des instructions SQL écrites sous forme de chaînes Java (s'il vous plaît pas de guerres de flamme OR / M, le SQL intégré est ce qu'il est - pas ma décision).

J'ai divisé les instructions SQL sémantiquement en plusieurs chaînes concaténées sur plusieurs lignes de code pour faciliter la maintenance. Donc, au lieu de quelque chose comme:

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

J'ai quelque chose comme:

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

Ce style rend le SQL beaucoup plus facile à lire et à maintenir (IMHO), en particulier pour les requêtes plus volumineuses. Par exemple, je peux mettre mon éditeur en mode "écraser" et modifier le texte en place assez facilement.

Notez que ce problème se généralise au-delà de l'exemple particulier de SQL. Tout code écrit avec n'importe quel format vertical, en particulier les constructions tabulaires, est susceptible d'être détruit par une jolie imprimante.

Désormais, certains membres du projet utilisent l'éditeur Eclipse et la mise en forme sémantique est souvent détruite lorsqu'ils mettent en forme un fichier source entier.

Existe-t-il un moyen de demander à Eclipse d'ignorer certaines lignes de source en ce qui concerne le formatage?

Je cherche quelque chose comme un commentaire spécial qui bascule le formateur Eclipse. Idéalement, un tel commentaire pourrait être configurable pour être celui que nous choisissons, et d'autres formateurs pourraient également être programmés pour le respecter:

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

Évidemment, une «solution» consiste à faire normaliser les membres de notre équipe sur un formateur externe comme Jalopy ou JIndent , mais ce n'est pas de cela qu'il s'agit (également, pas ma décision sur ce projet): je cherche spécifiquement un moyen de éviter le formateur Eclipse sur une base ad hoc.

Idéalement, une solution me permettra d'insérer des instructions pour le formateur Eclipse sans obliger les membres de l'équipe utilisant Eclipse à effectuer une reconfiguration IDE (autre que le choix éventuel d'un commentaire de commande agnostique du formateur: STOP-ECLIPSE-FORMATTINGSTOP-FORMATTING).


1
Nous avons eu ce problème. Eclipse devrait avoir une option pour toujours couper une ligne dans un constructeur String où se trouve un +, indépendamment du fait que le prochain bit de chaîne tienne sur la ligne. Mais ce n'est pas le cas. :-(
JeeBee

Apparemment, cette fonctionnalité a été ajoutée dans Eclipse 3.6M6: bugs.eclipse.org/bugs/show_bug.cgi?id=27079
Guillaume

Remarque: Si vous voulez simplement empêcher l'éclipse de gâcher vos commentaires, vous pouvez utiliser // devant chaque ligne. Pour commenter un bloc, mettez en surbrillance et appuyez sur Ctrl + /.
John Henckel

Notez que maintenant 10 ans plus tard, Java 14 apportera probablement des chaînes multi-lignes, ce qui appartient au passé.
Thorbjørn Ravn Andersen

Réponses:


866

Eclipse 3.6 vous permet de désactiver la mise en forme en plaçant un commentaire spécial, comme

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

Les / désactiver les fonctions doivent être mis « sur » dans les préférences Eclipse: Java > Code Style > Formatter. Cliquez sur Edit, Off/On Tags, activez Enable Off/On tags.

Il est également possible de changer les chaînes magiques dans les préférences - consultez la documentation Eclipse 3.6 ici .

Plus d'information

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

Cette préférence vous permet de définir une balise à désactiver et une balise pour activer le formateur (voir l'onglet Balises Off / On dans votre profil de formateur):

entrez la description de l'image ici

Vous devez également activer les drapeaux de Java Formatting


7
L'option "Ne jamais joindre des lignes" qui est mentionnée ailleurs dans cette page est également très utile.
xpmatteo

89
Les fonctions d'activation / désactivation doivent être activées. Dans les préférences Eclipse: Java> Style de code> Formateur. Cliquez sur le bouton "Modifier", "Balises Off / On", cochez "Activer les balises Off / On".
Domenic D.

2
Ce n'est pas disponible dans les préférences de style de code JavaScript , où j'ai exactement le problème opposé avec la mise en forme. :(
Redsandro

11
Les équipes doivent exporter une copie des préférences Eclipse (fichier) sur leur wiki et exiger que tout le monde utilise le même. Fonctionne bien pour nous. ;)
Joseph Lust

Pour info, j'ai dû supprimer l'espace entre le // et le signe @ pour que cela fonctionne.
Roy Truelove

61

AFAIK d'Eclipse 3.5 M4 sur le formateur a une option "Never Join Lines" qui préserve les sauts de lignes utilisateur. Peut-être que cela fait ce que vous voulez.

Sinon, il y a ce vilain hack

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

1
Donc, en plus de définir l'option "Ne jamais joindre des lignes", je dois également écrire ces commentaires "fantômes"? La partie "Never Join Lines" ne devrait-elle pas fonctionner seule?
Greg Mattes

2
Oui, bien sûr. Les commentaires fantômes sont une approche alternative (au cas où il n'existe pas, ou si vous êtes bloqué avec une version antérieure, etc.).
Chris

J'ai utilisé cette approche en tandem avec un modèle de formatage personnalisé dans TOAD pour me permettre de supprimer l'ancien SQL du code JAVA, de le reformater et d'obtenir tous les commentaires superflus, puis de le renvoyer dans JAVA. C'est une douleur, mais cela nous a permis de formater automatiquement en enregistrant notre code Java maintenant. Merci pour la suggestion!
jnt30

Sans cocher la case "Ne jamais joindre des lignes", les macros marche / arrêt ne fonctionnent pas pour moi - merci!
Christoffer Soop

28

Voir cette réponse sur SO .

Il existe une autre solution que vous pouvez utiliser pour supprimer la mise en forme de commentaires de bloc spécifiques. Utilisez /*-(notez le trait d'union) au début du commentaire de bloc et la mise en forme ne sera pas affectée si vous formatez le reste du fichier.

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

Source: Documentation chez Oracle .


2
C'est la meilleure réponse car elle ne dépend pas de la configuration de l'IDE de l'utilisateur. Merci.
Azim

26

Au lieu de désactiver le formatage, vous pouvez le configurer pour ne pas joindre les lignes déjà encapsulées. Semblable à la réponse de Jitter, voici pour Eclipse STS:

Propriétés → Style de code Java → Formateur → Activer les paramètres spécifiques au projet OU Configurer les paramètres de l'espace de travail → Modifier → Habillage de ligne (onglet) → cocher "Ne jamais joindre des lignes déjà encapsulées"

Enregistrez, appliquez.

entrez la description de l'image ici


1
Je pense que cela aiderait des choses comme l'exemple SQL, mais je ne suis pas sûr que ce serait suffisant pour le cas général de désactivation complète du formateur IDE.
Greg Mattes

2
Cette solution est excellente lors de l'utilisation du modèle de générateur et sa pertinence est certainement augmentée avec l'introduction de lambdas dans Java 8.
Jonas Kongslund

16

Vous devez activer la possibilité d'ajouter les balises du formateur. Dans la barre de menus, accédez à:

Windows Preferences Java Code Style Formatter

Appuyez sur le Editbouton. Choisissez le dernier onglet. Remarquez la case On / Off et activez-les avec une case à cocher.


14

Si vous mettez le signe plus au début de la ligne, il formate différemment:

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

1
Cela pourrait être un compromis intéressant. En général, je voudrais m'abstenir de trop modifier la mise en forme du code en raison d'un comportement indésirable d'un outil. Dans ce cas, les opérateurs de concaténation de chaînes sont plus un accident que l'essence de ce qui se passe avec le SQL. C'est pourquoi je préfère les écrire à la fin de chaque ligne. Je pense que le SQL doit être souligné comme le début de la ligne. Mais cela peut être une bonne façon de procéder en l'absence d'une solution qui me permet de conserver la mise en forme souhaitée. Merci!
Greg Mattes

8
Je vous en prie. En fait, je mets mes signes + en première ligne depuis des décennies, et pas pour tromper le formateur. Je les préfère à l'avant, car cela me rend plus clair ce qui se passe: ce qui se trouve au bout d'une ligne se perd parfois. C'était la norme du projet quelque part en arrière lorsque nous utilisions des compilateurs à bois, et cela m'est resté.
CPerkins

5

J'utilise des parties de chaîne de largeur fixe (remplies d'espaces) pour éviter que le formateur ne gâche mon indentation de chaîne SQL. Cela vous donne des résultats mitigés et ne fonctionnera pas lorsque les espaces ne sont pas ignorés comme dans SQL, mais peuvent être utiles.

    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

Terminez chacune des lignes par une double barre oblique "//". Cela empêchera l'éclipse de les déplacer tous sur la même ligne.


4

Méthode alternative: dans Eclipse 3.6, sous "Line Wrapping" puis "General Settings" il y a une option pour "Ne jamais joindre des lignes déjà wrappées". Cela signifie que le formateur encapsulera de longues lignes mais n'annulera aucun emballage que vous avez déjà.


4

@xpmatteo a la solution pour désactiver des parties de code, mais en plus de cela, les paramètres d'éclipse par défaut doivent être définis pour ne formater que les lignes de code modifiées au lieu du fichier entier.

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

Cela aurait empêché cela de se produire en premier lieu puisque vos collègues reformatent du code qu'ils n'ont pas réellement changé. Il s'agit d'une bonne pratique pour éviter les incidents qui rendent le diff sur votre contrôle de source inutile (lorsqu'un fichier entier est reformaté en raison de différences de réglage de format mineures).

Cela empêcherait également le reformatage si l'option on / off tags était désactivée.


2

Les commentaires fantômes, ajoutant //où vous voulez de nouvelles lignes, sont super!

  1. @Formatter: off ajoute une référence du code à l'éditeur. Le code ne devrait, à mon avis, jamais avoir de telles références.

  2. Les commentaires fantômes (//) fonctionneront quel que soit l'outil de formatage utilisé. Peu importe Eclipse ou InteliJ ou tout éditeur que vous utilisez. Cela fonctionne même avec le très joli format Google Java

  3. Les commentaires fantômes (//) fonctionneront partout dans votre application. Si vous avez également Javascript et utilisez peut-être quelque chose comme JSBeautifier . Vous pouvez également avoir un style de code similaire dans Javascript.

  4. En fait, vous voulez probablement un formatage correct? Vous souhaitez supprimer les espaces / tabulations mixtes et les espaces de fin. Vous souhaitez mettre en retrait les lignes selon la norme de code. Ce que vous ne voulez pas, c'est une longue file d'attente. Voilà, et seulement cela, ce que le commentaire fantôme vous donne!


-3

Ce hack fonctionne:

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

Je suggère de ne pas utiliser le formateur. Un mauvais code devrait être mauvais et non artificiellement bon. Un bon code prend du temps. Vous ne pouvez pas tricher sur la qualité. Le formatage fait partie de la qualité du code source.


8
Ne pas utiliser le formateur est juste une mauvaise idée; le formateur aide à détecter les erreurs et maintient le code dans un état cohérent.
Francis Upton IV

Une suggestion intéressante, mais je ne vois pas comment le formatage nous dit si le code est bon ou non.
Chris

2
Je pense que ce qu'il dit, c'est qu'il estime que le code mal écrit et mal formaté devrait être conservé tel quel plutôt que de le formater dans l'espoir de «l'améliorer». Un code mal écrit et mal formaté devrait «ressortir» d'une manière ou d'une autre pour être facilement identifié. Pas tout à fait sûr que je suis totalement d'accord, mais je pense que c'est l'idée.
Greg Mattes

1
@Francis - Bugs: Comment le code auto-formaté peut-il trouver des bugs? Cohérence: la cohérence est un bon argument mais la qualité globale du code est plus importante. Vous pouvez définir un processus cohérent agréable pour retourner les hamburgers, mais cela ne fonctionnera jamais pour la haute cuisine. Cuisiner un peut être une activité raisonnablement compliquée ou triviale si vous ignorez suffisamment de faits. Si vous pensez que le développement de logiciels est comme des outils de retournement de hamburgers, l'application de la cohérence est faite pour vous. Ce n'est pas un argument contre les lignes directrices de formatage, mais si les développeurs ne se soucient pas de ces directives, ils ne se soucieront pas des autres éléments essentiels.
Thomas Jung

4
Mon argument ici: j'écris du bon code et je m'en tiens aux lignes directrices de formatage. Mais je suis paresseux. Pourquoi devrais-je avoir à insérer la bonne quantité d'espaces et de sauts de ligne quand je peux écrire mes cinq lignes de code bâclé, appuyer sur le bouton de formatage et être satisfait? APRÈS avoir formaté le code, en utilisant mon outil qui garantit que le résultat est toujours parfait, je suis aussi nazi que quiconque sur le formatage. Il n'y a AUCUN argument contre le respect des lignes directrices (à part qu'elles peuvent être particulièrement mauvaises) si la mise en forme est juste à côté. Tous les membres du projet partagent les mêmes paramètres de formatage de code.
Par Wiklander
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.