LMAX-Architecture

Code propre et compact

Convention de code

Pour chaque langage de programmation, il existe une ou plusieurs normes de programmations spécifiques, définies par des standards ISO. En C par exemple, il existe la norme ANSI C ou la norme C99. Le document suivant est une compilation de différentes normes permettant d'élaborer des conventions de programmation plus ou moins génériques, sortes de préceptes pour un code propre. En tant que conventions, les arrangements ci-dessous présentent des choix arbitraires, réfléchis toutefois pour structurer le code selon un maximum de clarté et de logique.

Certains pensent que structurer, indenter, commenter est une perte de temps dans le processus de création de code et développent donc en deux temps: coder moche puis réindenter -et commenter à peine. Ceux-là se trompent gravement: coder propre et respecter dès le début d'un projet des conventions strictes permet un gain de temps considérable sur le long terme. Dès que le programme se complexifie, que les contributeurs se multiplient, que des relectures et des mises à jour doivent être faites, l'avantage d'un code propre est un bénéfice immense. Le suivi et la rigueur des conventions, la structuration logique et réfléchie ainsi que les commentaires abondants et pertinents marquent la différence entre un code propre, beau et admirable et le code juste 'qui marche', produit par le développeur moyen.

Convention de documentation

• en-tête de fichier : En début de tous les fichiers sources, créer un cartouche d'en-tête contenant au minimum le nom du fichier, une brève description de son utilité, le numéro de version, la date de dernière mise à jour, le nom du responsable du module ou du développeur.
• - prototype et déclaration de fonction : Devant chaque prototype de fonction (.h) ou encore devant chaque corps de fonction (.c), indiquer brièvement l'utilité de la fonction ainsi que les domaines de validité des paramètres. En Java, cette fonctionnalité peut être remplie automatiquement par des plugins pour Eclipse comme JAutodoc.
• - dans le code : Commenter chaque partie réalisant une tâche importante. En général, commenter le but du code suffit. Le lecteur devra être capable de retrouver le 'comment' rien que par la lecture du code qui de lui-même doit-être suffisamment claire. Le choix de variables explicites, la structure claire et l'indentation stricte permettent de faciliter cette compréhension. Rappelez-vous: 'un code admirable n'est pas une résolution complexe écrite en peu de lignes, mais une résolution complexe écrite de sorte à être lu sans effort par un novice'.
• - Préfixer les commentaires: Dans le cas d'un développement en équipe, il peut être utile de préfixer les commentaires d'un code auteur. Ceci permet de retrouver si besoin l'auteur du code pour en connaître les spécificités.

2 conseils supplémentaires

• - Couper n'est pas copier: D'une manière générale, la fonction copier pourrait être désactivée des environnements de développement. Dite ainsi, la mesure paraît drastique, mais l'explication est simple. Si vous avez besoin de copier-coller un bout de code d'un endroit à un autre de votre programme, c'est très souvent que ce morceau mérite d'être transformé en une fonction (ou en méthode en Java). Ainsi, vous n'aurez plus besoin de rallonger votre code mais pourrez faire un appel à la-dite fonction. Pondérez cependant ce fait en considérant qu'une multiplication excessive de fonctions est nuisible à la lecture et la compréhension rapide du code. Comme pour chacune des préconisations de cet article, tout est une question de compromis.
• - Supprimer le code mort: Bien souvent dans les contributions, il est donné de voir des parties entières de code mises en commentaires. Ces parties de code étant obsolètes, l'auteur les a commentées sans les supprimer: dommage! Bien plus grave, quand des parties de code mort (jamais exécutées) sont laissées tel quel, même pas commentées. Toute fonction, méthode, classe, structure ou variable n'étant plus utilisé doit être supprimée du code.