-------[ RtC Mag, At the end of the universe ] --------------[ Coding Art ] ---------[ in RtC mag 5 ] ----[ by S/ash [RtC] ] Ceci n'est pas un article sur la programmation en elle-même mais plutôt sur la façon de présenter un fichier source. J'expliquerai ici dans le cas du langage C/C++ mais cela est extensible à tous les autres langages. -------[ I. L'indentation Votre code source doit avoir une identation cohérente (façon de disposer les espaces et les autres symboles dans un code source) et surtout elle doit être homogène dans tous les fichiers sources d'un même programme (pour ma part j'utilise celle par défaut d'Emacs). Evitez surtout l'utilisation des tabulations (à moins que votre éditeur ne les remplace automatiquement par des espaces) : cela détruit complètement l'identation à l'ouverture du code source sur un éditeur différent !!! -------[ II. Les fonctions Les fonctions ne doivent pas être trop grosses (une règle appliqué dans certains établissements est de ne pas dépasser 25 ou 30 lignes de code par fonctions). Chaque fonction doit avoir pour but une seule action : on ne doit pas réunir par exemple, une fonction d'ouverture d'un fichier avec une autre d'enregistrement. -------[ III. Le nommage des variables et fonctions Chaque fonction ou variable doit avoir un nom clair et précis. Ce nom ne doit cependant pas être trop long (C'est chiant à taper 20 caractères). Par exemple, un index de boucles ou de tableau va être nommé i ou j ou k... Un autre exemple est si j'ai une fonction qui va classer une liste de fichier par date, il ne faut pas la nommer fonction_qui_classe_par_date mais plutôt classe_date (moi je l'appelerai personnellement datesort). De même, il faut que vous ayez une facon de nommer cohérente dans un code source (par exmple je nomme pour des fonctions classiques en C en miniscule avec des underscores (_) si nécessaire et les fonctions destinée à être réutilisée avec des majuscules au début des mots (CommeCeci)). Dans certains cas on peu négliger le nommage comme lors de variables temporaires ou de fonction ne servant qu'à un endroit (utilisée par exemple dans une fonction de tri). Il est également inutile de se tracasser sur les arguments des fonctions triviales (d'initialisation en particulier). Le mieux est encore d'adopter une convention clairement expliqué dans un fichier join à vos source. Le top en matière de convention de nommage est lorsque, par exemple, on dit que tout les noms seront du type ab_Nom ou a est une lettre ou une série de lettre désignant le type de variables (p pour pointeur ou pi pour pointeur sur entier) et b la portée de la variables (g pour globales, l pour locales...) et enfin Nom est un nom explicite (ce type de nommage est rapidement chiant pour le codeur mais très pratiques pour le relecteur). Une de ces conventions est celle prise par Micro$oft pour les fonctions de l'API windows nommée notation Hongroise. -------[ IV. L'organisation des modules Les modules (en générales les différents fichiers sources) doivent chacun avoir une fonction précisent sans aller empietiner sur les autres... On ne doit pas écrire dans un même modules par exemple, les fonctions algorithmiques et les fonctions d'interfaces. -------[ V. Les commentaires Les codes sources doivent être pleinement accompagné de commentaire. Tout d'abord chaque fichier doit contenir un en-tête expliquant à quoi sert le fichier. Ensuite chaque fonction doit être commenté par un petit texte clair. Pour ma part je mets également lors des fonctions non triviales la liste des entrées et sorties de la fonction. Chaque bouts de code doit être expliqué pour dire ce qu'il fait et, si on a le courage, comment on le fait. Enfin, les lignes qui sembles compliqué ou les algorithmes un peu ardu doivent être expliqué dans leur méthode (ca je ne le fais pas tous le temps). -------[ VI. A quoi ca sert tout ça ? Ben, dans la plupart des cas, un code source est fait pour être diffusé (c'est ma philosophie) ou du moins révisé et corrigé. Ceci facilitera la chasse aux bugs, la compréhension des autres sur le code et vos futures relectures... -------[ Un petit dernier mot... L'art du codage est surtout une histoire de bon sens, il s'agit simplement de rendre un code clair et non de retrouver lecharabia que l'on peut voir dans certaines sources comme celle de certains auteurs de la GNU ou de chez M$... L'art du codage est une route longue et difficile. En effet, écrire un code source clair et compréhensible n'est pas une chose aisée. Pour ma part, le summum dans ce domaine est une technique que j'ai vu dans une boîte ayant été classé premier européen en qualité logicielle. -------[ EOF