Coma Informatique

J’entends quelquefois parler de code élégant. On pourrait alors écrire du code source qui allierait la grâce, la distinction et la simplicité ?

En ce qui concerne la grâce et la distinction, croyez-vous que ces adjectifs qualifient bien ceci :

#include

}


Ou bien ceci :

class HelloWorld {

Franchement autant chercher de la beauté dans un boulon ! Reste la simplicité et on peut qualifier les exemples précédents de code simple.

J’ai souvent entendu des pratiquants d’extreme programming parler de code élégant, alors que XP préconise d’écrire le code le plus simple qui puisse marcher. Le terme élégance est donc une façon de parler de simplicité mais d’une manière plus positive, car pour beaucoup simple = simpliste.

Pour ma part, à une hypothétique élégance, je préfère donc parler de simplicité et de clarté.

Un code simple et clair est plus facile à comprendre qu’un code alambiqué. C’est important car on passe finalement plus de temps à modifier du code qu’a en écrire, que ce soit lors de la mise au point initiale, ou lors des phases de maintenance.

Pour obtenir un code simple et clair il suffit de suivre quelque principes simples à mettre en oeuvres :

• Intention. Le code doit exprimer l’intention du développeur. Préférer les formes claires plutôt que les syntaxes compactes. Par exemple éviter ce type de syntaxe :
  table[(ligne[coll--]++)+offset[++coll]--]--;
• Noms expressifs. Utiliser des noms parlants, que ce soit pour le nom de fichier, le nom de classe, d’attributs, de méthode, etc. Aujourd’hui les systèmes d’exploitation et les langages modernes n’impose plus de limites (ou très peu) dans ce domaine. Évitez les noms bateaux comme titi, toto, dummy, temp, etc, qui en plus de limiter la clarté peuvent aussi provoquer des bugs.
• Éviter les littéraux. Préférer les énumération ou les constantes plutôt que des valeurs littérales. Par exemple :
  MessageBox.Show("Salut", MessageBox.ShowButton.Ok);
  est plus clair que
  MessageBox.Show("Salut", 3);
  De même l’utilisation de ressources ou de constantes pour les chaînes de caractères rendront une traduction beaucoup plus facile.
• Paramètres explicites. Eviter l’utilisation des valeurs par défaut lors de l’utilisation de méthode. Il s’agit donc de définir de façon explicite les valeurs des paramètres plutôt que d’utiliser les valeurs implicites. Ceci afin d’une part d’expliciter ce que vous voulez faire, et d’autre part éviter l’apparition de bugs en cas de changement des valeurs par défaut.
• Règles de nommage simples. Définir une règle de nommage simple et la respecter ! Il n’est pas nécessaire d’utiliser une règle complexe comme la notation hongroise, au contraire. Le fait de respecter une règle même simple rendra la lecture du code plus rapide car certaines constructions apparaîtront visuellement. A l’inverse une règle complexe et contraignante ralenti l’écriture et n’apporte rien en terme de clarté. En général si une règle ne peut pas tenir sur une page A4 placée sur le bureau de chaque développeur elle ne servira à rien !
• Tests unitaires. Écrire des tests unitaires pour chaque méthodes ou fonctions. Non seulement le code écrit sera de meilleure qualité, mais encore les tests deviendront un point d’entrée dans le code puisqu’ils décrivent ce que le code doit faire.
• Remaniement constant. Ne pas hésiter à remanier constamment son code (refactoring) afin de le garder simple et clair. Consulter l’ouvrage de référence de Martin Fowler, Refactoring: Improving the Design of Existing Code.

Si vous avez d’autres principes à me proposer, n’hésitez pas !

Cet article a été publié par Alexis KARTMANN le Jeudi 10 mars 2005 à 11:32 et est classé dans Aucun tag pour cet article..
Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.