Pourquoi utiliser des conventions de codage ?
Tout d’abord le respect de règles de codage facilite la maintenance du code lorsque vous travaillez en équipe. Il faut savoir que le code passe 80% de son existence en phase de maintenance. Lors des phases de relecture ou de corrections de bugs, le respect de convention de nommage et de codage permettent de gagner du temps pour se concentrer uniquement sur le contenu. D’autre part, un problème existe si vous utilisez un gestionnaire de source comme CVS, VSS ou SVN et différents IDE Java. Eclipse ou IDEA d’IntelliJ ont tout les 2 une fonction de mise en page automatique. Lorsque vous ouvrez un fichier, celui-ci est réarrangé selon vos règles de codage. Si chaque développeur a des conventions différentes, il va créer des différences ligne par ligne qui n’en sont pas réellement à chaque fois qu’il va commiter son fichier. C’est ensuite le cauchemar lorsque vous voulez comparer 2 révisions. Impossible de comprendre ce que la personne a réellement ajouté ou modifié. D’où l’importance de fixer des conventions de codage: la tabulation est de 4 caracteres avec des espaces, les accolades se mettent en bout de ligne, les classes sont nommés avec une majuscule comme première lettre (MyClass et pas maclasse_qui_fait_qqchose) etc.
Ce que font les autres:
Si vous avez l’habitude de jeter un oeil sur les projets open-source Java sur Internet, vous verrez qu’à de rares exceptions, chaque classe est codée de la même manière. Les projets open-source forcent les contributeurs à suivre leurs règles de codage. Cela facilite le travail des personnes qui valident les patches, et permet à tout le monde de partager son code. Pourquoi partager ? Laisser un développeur coder à sa manière dans une équipe reviendrait à lui donner une proprieté sur le code. Or le principe des méthodes de projet Agile comme l’eXtreme Programming est que le code n’appartient pas à un développeur précis. Il peut se référencer comme étant l’un des auteurs, c’est le rôle de la balise @author de la javadoc. Par contre, rien ne doit empecher un autre développeur d’ouvrir le fichier et d’y apporter sa contribution. Cela facilite la relecture, les apports d’amélioration et favorise la communication. Pour communiquer efficacement, il faut simplement se mettre d’accord sur des conventions de codage. D’où la question suivante:
Quelles conventions de codage utiliser ?
Vous pouvez partir d’un consensus au sein de l’équipe ou tenter d’utiliser les conventions proposées par SUN. Pour notre équipe, la discussion fut vite reglée: nous utilisons tous IDEA IntelliJ qui par défaut se calque sur les conventions de SUN. Nous n’avons pas personnalisé les réglages. L’avantage d’IntelliJ est de proposer une fonction de reformatage du code qui permet de parser et arranger un fichier Java selon des règles établies à l’avance (voir aussi cette page d’aide). Certe il n’est pas gratuit par rapport à Eclipse, mais c’est tout simplement le meilleur IDE Java à ma connaissance. Et je dis cela alors que j’étais un utilisateur accro à NetBeans auparavant.
Quelques conventions de codage
Difficile de changer ses habitudes. Ceux qui sont habitués à placer les accolades à la ligne ont du mal à revenir aux conventions de SUN qui imposent de placer les accolades en bout de ligne. Avec un éditeur moderne comme Eclipse ou IntelliJ, les blocs d’instruction sont mis en valeur et il est possible d’ajouter des séparateurs virtuels avec IntelliJ. Voyez la capture d’écran ci-dessous, cliquez sur l’image pour l’afficher dans une autre fenêtre de votre navigateur: 
. Le fait de placer les accolades sur chaque nouvelle ligne ne vous apportera donc pas grand chose de plus, si ce n’est plus de lignes de codes pour rien.
Should we code in english ?
L’utilisation du français ou de l’anglais. C’est un sujet assez vaste. Faut-il coder en anglais ou non ? Est-ce que l’on préfere ParseurDynamiqueImplementation ou DynamicParserImpl ? Est-ce que la javadoc doit être rédigée en anglais ou non ? Si vous codez votre projet dans votre coin, rien ne vous force à utiliser l’anglais. Si vous êtes plus à l’aise pour expliquer et commenter votre code en français, alors pourquoi se géner ? Si vous contriburer à un projet open-source, même si celui-ci est francophone, vous verrez que toute la communauté des développeurs open-source java utilise l’anglais comme langue de travail. J’avoue que cela fait maintenant 8 ans que j’ai pris cette habitude, et que ce soit ma première applet à l’époque ou aujourd’hui une librairie de composant JSF, je n’utilise que l’anglais. C’est comme le vélo: on tombe au début mais une fois que l’on a compris, tout roule. Enfin j’exclu le grand débat des forcenés du français qui pensent qu’il faut utiliser uniquement le français. C’est vrai dans l’absolu et je respecte beaucoup le travail de l’Office québécois de la langue française par exemple. Pour ce qui est de programmer en Java, la question ne se pose pas. Ou alors il faut faire un autre boulot…
Pour conclure, les règles de codage sont importantes voir indispensables au sein d’une équipe. Vous pouvez vous aider grâce à des outils comme Jalopy ou JxBeauty si vos développeurs ne le font pas eux-même, mais je pense que cela serait dommage. Cette page vous donne les adresses de Jalopy ou autre si vous voulez les essayer. Sinon Eclipse ou IntelliJ à la place de vi (mon favori) ou emacs pourront améliorer la productivité et la qualité du code. Mais là je glisse sur un autre débat que je garderai pour un autre post…
0 no like
