Commité de normalisation TI_C
Voici le premier essai de norme concernant la lisibilité des codes sources en C.
Je ne sais guère si ceci sera respecté, mais j'espère que ce soit le cas.
Pourquoi une telle "Norme" ?
ETant donné le tutorial pour le language C appliqué aux calculatrices Texas Instrument, modèles TI-89 et TI-92+, que j'ai, avec les autres membres de la TCI, été amené à rédiger, j'ai souvent l'occasion de recevoir des codes sources (provenant généralement de débutants) assez peu lisibles, ne fonctionnant pas pour des raisons variables.
Dans le but de corriger les erreurs présentes dans ces codes sources, et faire ainsi fonctionner les programmes qui me sont envoyés, afin de pouvoir venir en aide à la personne me l'ayant demandé, je suis nécessairement obligé de chercher à comprendre le programme.
Mais, parfois, la mauvaise ordonnance de son code source me rend la compréhension difficile, et il n'est malheureusement pas (assez) rare que je doivent réorganiser le code, le réarranger, voire même le réécrire dans son intégralité (ou quasi-intégralité), ce qui constitue pour moi une énorme perte de temps, et qui est parfois à l'origine d'une non-réponse de ma part à la question qui m'était posée, tout simplement parce que je n'ai pu trouver le temps nécessaire à cette "remise en page".
Passées ces motivations purement égoistes, et souhaitant étendre cette réflexion à un environement plus "global", je suis venu à me poser des questions sur les codes sources disponibles sur Internet, pardois diffusés avec le programme dont ils constituent la base. Je sais que ces codes sont parfois utilisés par des débutants souhaitant apprendre le C, et je suis intimement convaincu qu'ils leur seraient plus faciles d'accès si tous présentaient quelques points communs (mis à part le fait qu'ils soient écrit en C !).
Je suis d'avis (et ce que certaines personnes ont déclarée sur un forum où la question fut posée) que l'introduction de certains "standards" somme toute simples à mettre en oeuvre faciliterai grandement la compréhension de programmes écrits par d'autres programmeurs.
Je sais que ce projet, cette norme, si tant est que nous puissions lui appliquer ce terme, recontrera des détracteurs, mais j'ai plaisir à croire que cela permettra d'aider quelques débutants à comprendre ce language que nous apprécions tant !
Je tiens à préciser que je ne me permettrait pas de qualifier le respect d'une telle convention d'écriture comme obligatoire, et tiens à mettre immédiatement certaines choses au clair :
1: Vous n'êtes nullement obligé de respecter une telle idée !
2: Pour les codes sources que vous n'avez pas l'intention de distribuer, vous agissez comme bon vous semble !
3: Pour les codes sources que vous distribuez, une telle convention peut permettre aux lecteurs de mieux comprendre vos intentions. Ainsi, une code comportant en en-tête quelque chose du style "Conforme à la convention TI_C_machinchose portant sur les noms de variables" signifiera qu'il respecte ce qui est ici écrit, et qu'il est conforme au souhait de volonté de facilité de relecture que nous avons émis.
La première idée que je me permet de proposer est, je le reconnais, quelque peu inspirée de la notation hongroise utilisé principalement par MicroSoft (notament pour la programmation sous interface Windows). Cette technique rencontre parfois une ferme opposition, mais je la trouve appréciable, notament dans des cas comme celui qui nous interesse.
Elle consiste à préfixer les noms de variables de quelques lettres (entre 1 et 3 généralement) qui décrivent son type. Ensuite, viendrait le caractère '_', utilisé comme séparateur entre le type de la variable, et son nom effectif..
Par exemple, si nous déclarons une variable de type TYPE, nous lui donnerions un nom précédé des lettres "TYP", par exemple, une peu comme ceci :
TYPE TYP_ma_variable;
Voici les différentes propositions que je peux actuellement faire :
----------------------------------- | Type effectif | | | de la variable | Préfixe | ----------------------------------- | char | C _ | | unsigned char | UC _ | | short (int) | S _ | | unsigned short | US _ | | int (short ou long) | INT_ | | unsigned int | UINT_ | | long | L_ | | unsigned long | UL_ | | float (=double) | F_ | | HANDLE | H_ | | SYM_ENTRY | SYM_ | | | | | | | | | | | | | | | | | | | | | | -----------------------------------
D'autres normes peuvent être fixées en fonction de l'usage de la variable.
Ainsi, par habitude, les variables utilisées comme compteur (par exemple dans les structures itératives, telles la boucle for), sont nommées i.
Dans un tel cas, nous utiliserons une écriture de ce style :
short S_i_1; // Déclaration de la variable de compteur.
for(S_i_1=0 ; S_i_1<10 ; S_i_1++)
{
// exécutions de quelques instructions...
}
Nous respecterons cette habitude, en préfixant certaines variables en fonction de leur usage.
Voici les différentes propositions que je peux actuellement faire :
----------------------------------- | usage de | | | a variable | Préfixe | ----------------------------------- | compteur | i_ | | | | | | | | | | | | | | | | | | | | | | | | | | | | -----------------------------------
Cependant, j'insiste, et je n'insisterai jamais assez, sur le fait que de tels préfixes sont totalement inutiles si vous employés des noms de variables pour le moins obscur.
Je m'explique :
Tous les noms de variable du style
ma_var1_, ma_var_2, ma_var_3
et autres, sont totalement à proscrire.
Il est nettement plus explicite de les nommer, par exemple, selon le contexte, de la façon suivante :
position_heros_x, position_heros_y
dans le cadre, ici, d'un jeu où la position du héros puisse être définie selon une coordonnée en X et une coordonnée en Y.
Les données constantes (les constantes symboliques définies au niveau préprocesseur par la commande #define) porteront des noms écrits intégralement en majuscules, et ne comportant aucun préfixe.
Par exemple :
#define MA_CONSTANTE 10 // défini une constante valant 10.
Bon, voila, j'ai proposé...
J'attend vos réactions, avant de rajouter d'autres types de données, complétant ainsi ce que j'ai ici rédigé.
Si jamais la réaction face à ma proposition est positive, et que nous parvenons, ensemble, à nous mettre d'accord sur quelque chose de correct aux yeux de la majorité, j'ai la ferme intention de rendre mon tutorial "compatible" à cette norme une fois qu'elle sera achevée.
Je vais insiter sur une dernière chose : faire entrer de telles choses dans ses habitudes de programmation est chose difficile... Mais je sais que, une fois celle-ci prise, elle ne peut être que bénéfique, que ce soit au programmeur, ou à ceux qui le liront.
quelque chose comme i_1 serait peut-être plus adéquat... (autrement dit, ne pas dire le type de la variable utilisée comme compteur)
).
!
