Après avoir vu pas mal de codes sources, je me permets aujourd’hui d’apporter ma pierre à l’édifice que forment les normes de codages et de développements. Ce document est amené à évoluer au fur et à mesure de mes lectures et des projets dans lesquels je “trempe”.

Règles générales :

1. Etablir des normes de codage et s’y tenir. Avoir un code lisible et bien indenté c’est le premier pas vers une démarche qualité efficace. Le nec plus ultra serait d’avoir des normes standards pour lesquels on pourrait utiliser un outil comme tidy pour reformater régulièrement tout le code source du projet tout au long de sa vie.
   Les normes de codage Java sont une excellente piste pour commencer.
2. Documenter les fonctionnalités développées. Tout le monde sait qu’il y a le cahier des charges et le livrable et qu’entre ses deux étapes, le projet arbore une forme plus ou moins abstraite. Bref, l’idée c’est de maintenir une liste la plus exhaustive possible des fonctionnalités développées, ce qui évite au fil du projet ou après sa livraison (TMA) de savoir ce qui a finalement été codé. Le cas échéant, aucune correction, évolution ne pourra être entreprise sans une phase couteuse de reverse engineering.
   N.B. normalement les fonctionnels du projet sont sensé maintenir ce document primordial mais la taille du projet fait qu’il n’est pas rare que ce soit au développeur que la tâche soit affectée.
3. Documenter les sources et générer régulièrement la documentation associée. Une doc non générée ne sert absolument à rien puisque personne ne s’y tiendra.

Dans le code :

1. Interdire les fonctions (méthodes) ayant plus de 5 paramètres.
   Le nombre 5 est arbitraire, tout utilisateur d’une fonction ou d’une méthode devrait être capable de mémoriser les arguments qui l’accompagne. Au delà de 7 arguments la méthode perd en ergonomie pour le développeur. Sa réutilisabilité est donc compromise.
2. Interdire les fonctions (méthodes) ayant des paramètres en entrée/sortie.
   J’ai effectivement croisé des méthodes java dont les paramètres (pointeurs) sont modifiés dans la méthode sans être désignés implicitement (par le nom de la méthode par exemple) comme étant les résultats de la méthode. Et ça : à débusquer c’est assez terrible.
3. Interdire les “obus”.
   J’entends par obus les indentations de code exagérées (genre trois “if” imbriqués ou pire trois boucles imbriquées). De manière générale à chaque fois que je pique une gueulante à ce sujet on me répond qu’il n’est pas possible de faire autrement. Et pourtant si : tout bloc en programmation peut se résumer à des pré-conditions, un ou plusieurs traitements simples et des post-conditions.
   Ce qui signifie donc qu’une méthode générique devrait se contenter
   1. de vérifier que les paramètres qu’on lui donne sont appropriés auquel cas on retournera une valeur par défaut ou une erreur.
   2. de faire un traitement, pas besoin de structure de bloc dans cette partie
   3. de vérifier que le traitement retourne bien des valeurs cohérentes.

De manière générale, il est possible d’utiliser des metrics pour évaluer la qualité de son code source et vérifier que celui-ci est conforme aux règles de bases (chercher “java metrics” sur google et vous tomberez sur le blog de Bruno Vernay qui en a sélectionné quelques uns qui sont open-sources.) Pour ma part j’utilise ce projet qui est un plugins pour Eclipse.

En architecture logiciel :

1. Livre incontournable chez Oreilly pour Java :
   Better, Faster, Lighter Java

Note pour plus tard : toute relecture est la bienvenue, vu que je ne prends pas le temps de le faire…