Lors du démarrage d’un projet sur lequel plusieurs développeurs vont être amenés à travailler, se pose très tôt la question des styles et règles de formatage à appliquer au code. En effet, afin de pouvoir comparer l’historique des révisions d’un fichier, une bonne pratique veut que l’on ne change pas les règles de formatage au cours de route. Si tel était le cas, les changements importants seraient noyés par les changements d’indentations et autres retours à la ligne.
Parmi les normes de développements d’une entreprise ou d’un projet Open Source, un chapitre couvre généralement les règles de formatage. C’est par exemple le cas du guide de style de code du projet Spring Framework. Ces règles peuvent également être définies au sein d’un outil de qualimétrie comme SonarQube. Chaque violation de règle entraine alors un défaut.
Ce billet propose 2 solutions permettant à des développeurs IntelliJ, Spring Tools Suite (STS) et Eclipse de travailler ensemble.
Le formateur Eclipse
Nativement, Eclipse embarque un formateur de code source Java bien connu des développeurs. Afin de pouvoir partager des règles de formatage, il propose des fonctionnalités d’import / export. Au format XML, le fichier décrivant les règles de formatage est très répandu. Par exemple, le projet Spring AMQP fournit le fichier eclipse-code-formatter.xml. Ces règles peuvent être importés dans STS mais également dans IntelliJ IDEA via le plugin Eclipse Code Formater. Afin qu’aucune différence ne puisse être constaté entre du code formaté sous Eclipse et sous IntelliJ, ce plugin embarque directement le code du formateur d’Eclipse. Il existe un plugin similaire pour Netbeans, mais je ne l’ai jamais testé.
La principale limite du plugin Eclipse Code Formater réside dans le nombre de langages supportés : Java, GWT et JavaScript. Autrement dit, vos fichiers XML, pages JSP, HTML, et autres feuilles de styles CSS ne seront pas pris en compte. Le plugin est dépendant des fonctionnalités d’export d’Eclipse. Par exemple, il n’est actuellement pas possible d’exporter les règles de formatage du XML.
EditorConfig
J’ai découvert l’outil EditorConfig suite à une pull request réalisée sur le projet Spring Petclinic. Cet outil a fait ses preuves puisque de nombreux projets Open Source l’ont adopté : AngularJS, Jenkins, Bootstrap, WordPress …
La configuration d’EditorConfig est bien plus restreinte que celle du formateur d’Eclipse : seulement 8 paramètres dont le style d’indentation (espace ou tabulation), le nombre d’indentations, ou bien la suppression des espaces superflus en fin de ligne.
Là où il se distingue, c’est de pouvoir fixer l’encodage des fichiers et le type de retour à la ligne (Unix, Windows).
Sa configuration est simple. Voici le fichier .editorconfig mis en place sur Petclinic :
# Configuration racine pouvant être affinée pour chaque sous-répertoire
root = true
# Section de configuration valable pour tous les types de fichiers
[*]
# Encodage de des fichiers
charset = utf-8
# Fin de ligne à la Linux
end_of_line = lf
# Insère une ligne à la fin des fichiers
insert_final_newline = true
# Caractère espace pour indentater
indent_style = space
# Section de configuration spécifique aux classes Java et aux fichiers XML
[*.{java,xml}]
# Nombre d’espaces d’indentation
indent_size = 4
# Suppression des espaces de fin
trim_trailing_whitespace = true
Le principal avantage d’EditorConfig est le nombre d’éditeur de code supporté. Pas moins de 27. Certains nativement comme IntelliJ, WebStorm ou GitHub. Pour Eclipse, Netbeans ou encore Notepadd++, l’installation d’un plugin sera nécessaire.
Conclusion
Ce modeste billet vous aura montré 2 moyens de partager la configuration de vos formateurs, et ceci quelque soit votre IDE Java.
Pour des besoins simples, sur des projets multi-technos, EditorConfig est un bon candidat. Il convient également aux développeurs détestant que leur code soit formaté.
Pour une application d’Entreprise centrée sur Java, l’utilisation du formateur Eclipse reste à mon avis le meilleur choix.