Est-ce une bonne idée de formater le code en éclipse en utilisant le formatage automatique

J'utilise eclipse pour le codage, et le langage que nous utilisons est Java. Une fois, il a été suggéré par quelqu'un de formater correctement le code, en utilisant le formateur automatique (CTRL + MAJ + F). Bien que cette commande formate le code, mais parfois je pense que l'aspect global devient étrange et qu'il n'est pas vraiment très lisible.

Est-ce donc une chose recommandée à faire? Sinon, quoi de mieux que de formater notre code en éclipse?

Des règles de formatage de code strictes sont utiles lorsque plusieurs développeurs travaillent sur le même code à l'aide d'un système de contrôle de version. La fusion peut être pénible si différents développeurs ont des règles de mise en forme différentes car le même code serait différent pour l'outil de fusion.

Eclipse (ou tout autre IDE d'ailleurs) a des règles de formatage de code qui peuvent être personnalisées dans la section des préférences (Java> Style de code> Formateur). Choisissez ce que vous préférez, mais jetez également un œil aux conventions de code standard Java . De nombreux projets open source ont également leurs propres conventions de code qui peuvent être appliquées avec le formateur Eclipse.

De plus, il existe des outils standard comme CodeStyle, PMD et Findbugs qui appliquent des règles supplémentaires et aident à éviter les anti-modèles et les erreurs courants (de bas niveau).

J'ai trouvé la mise en forme automatique très utile. Au lieu de prendre constamment des microdécisions sur la façon dont le code doit être formaté - ce qui est sujet aux erreurs et provoque des "frictions cognitives" - vous pouvez définir des règles de formatage et laisser Eclipse formater le code pour vous (idéalement automatiquement en utilisant "Enregistrer les actions" ). Bien sûr, cela nécessite que vous ayez une base de code avec un formatage cohérent, ou que vous ayez le mandat de reformater le code selon les règles que vous avez définies.

Activer la mise en forme automatique lors de l'enregistrement est un peu comme avoir une compilation incrémentielle, cela permet à votre cerveau de rester concentré sur le code lui-même, au lieu de se préoccuper de problèmes triviaux tels que le formatage du code ou la syntaxe.

Mais oui, parfois, la mise en forme automatique va gâcher un tableau bien formaté que vous avez. Dans de tels cas, j'utilise des "balises on / off". Ceux-ci sont configurés sous l'onglet "balises on / off" dans le profil de formatage du code. En les utilisant, vous pouvez exclure les régions de votre code d'être formatées automatiquement:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

Que ce soit recommandé ou non, cela dépendra de qui vous demandez.

Je peux imaginer que vous préférez formater le code vous-même, après tout, vous savez ce qui est le mieux et le plus facile à lire par vous-même. Sur le plan positif, si vous êtes une personne prévenante, vous pouvez également la rendre plus lisible pour les autres êtres humains.

Les machines n'ont pas ce genre de prévoyance et peuvent (comme vous l'avez dit) faire ressembler votre code à un peu de gâchis, même si elles le formatent selon des règles strictes.

Un bon IDE ou un bon outil peut souvent faire un travail semi-décent pour formater le code pour vous, mais ne le rendra pas toujours aussi lisible que vous le pourriez.

Donc, mon conseil: ne l'utilisez pas sauf si vous recevez du code de quelqu'un d'autre, et c'est un tel gâchis que vous ne pouvez pas le lire autrement.

Vous devez l'utiliser tout le temps pour vous assurer que vous utilisez un style cohérent dans tous vos fichiers source. Cela vous fera également gagner beaucoup de temps que vous passeriez habituellement à essayer d'ajuster manuellement la mise en forme.

Le formateur Java dans Eclipse fait un très bon travail et est entièrement personnalisable. Si vous n'êtes pas d'accord avec les paramètres par défaut (que je peux comprendre complètement), vous devez alors ajuster le formateur selon vos préférences de style personnel ou quelle que soit la norme que vous utilisez. Vous pouvez le faire dans les préférences sous Java / Style de code / Formateur.

Les formateurs sont encore plus utiles lorsque vous ne travaillez pas seul. Il est très probable que vous et les membres de votre équipe soyez en désaccord sur ce que vous pensez être le style de code parfait ™. Dans ce cas, vous devez accepter une base commune et définir une fois pour toutes les règles de formatage pour ce style de code particulier. Ensuite, tout le monde peut simplement frapper le raccourci de formatage et tout correspond au style convenu. De cette façon, vos préférences personnelles (lors de l'écriture) ne vous gêneront pas. Et notez que le style du formateur peut être stocké dans les fichiers de projet d'Eclipse, donc différents formateurs pour chaque projet sont également possibles.

Bien que j'aime avoir le formatage automatique du code lors de la sauvegarde (en fait, je l'ai activé sur mes projets personnels). J'ai constaté que je ne pouvais pas recommander pleinement cette pratique dans les équipes de projet utilisant des produits basés sur Eclipse car le formateur Eclipse a des bogues critiques qui m'empêchent de le recommander.

Plus précisément, si vous avez "nettoyage de code" + "formateur" activé, les retraits sont fixes / non corrigés à chaque sauvegarde.

Chaque nouvelle version d'Eclipse peut changer le formateur (pour le mieux), mais introduirait des changements importants tels que JavaDocs supprimant finalement cet espace supplémentaire après le *mais qui a été introduit quelque temps après Helios et de nombreuses entreprises utilisent l'ancienne version Rational Software d'Eclipse. qui utilise Helios comme base.

Le formateur de code fourni par Eclipse n'est pas extensible par leur API, en fait, il indique explicitement CodeFormatter javadoc

Cette classe n'est pas destinée à être sous-classée par les clients.

Certes, je n'ai pas encore trouvé d' alternative non commerciale viable . Jalopy n'a pas été mis à jour depuis des années maintenant et les fourches dans github ne sont pas encore organisées pour me faire recommander l'un d'entre eux. Il n'a pas non plus de site de mise à jour pour qu'Eclipse l'intègre. Je prévoyais en fait de faire le formatage du code dans le cadre de la construction, tout comme je l'ai fait pour cleanpom-maven-plugin en utilisant Jalopy, mais cette idée est tombée à l'eau en raison du manque de mises à jour pour Jalopy.