I. Introduction▲
Charles Simonyi est né en 1948 à Budapest, en Hongrie. À 20 ans, il vient étudier l'informatique à l'Université de Berkeley aux États-Unis. Après avoir travaillé chez Xerox, il rentre en 1981 chez Microsoft où il est chargé de créer l'Application Software Group. Charles Simonyi prétend qu'il est capable de reconnaître si un programme a été écrit par son groupe de travail. Pourquoi cela ? Tout simplement parce que dans cette organisation, il a imposé certaines normes de programmation qui sont tellement caractéristiques que l'on peut les distinguer au premier coup d'œil. Les programmes Word et Multiplan de chez Microsoft ont été écrits en respectant ces conventions que l'on qualifie de hongroises par égard à la nationalité de Simonyi.
La notation hongroise est un ensemble de règles qui déterminent la formation des noms dans un programme. Cette convention vient du fait que si l'on examine un programme, on remarque que la grande partie du code source est constituée par des identificateurs. Les règles de la méthode hongroise permettent de créer automatiquement le nom d'un identificateur en prenant en compte ses propriétés.
Prenons un exemple extrait du logiciel Word (et dévoilé dans l'interview de Charles Simonyi extraite de l'ouvrage Les Princes du Soft publié chez Cedic/Nathan en 1986) :
La variable vbchrMac indique que la variable est globale (v), pointeur maximum actuel dépassant de 1 le dernier élément (Mac), basé sur un groupe (b) de structure chr.
II. Conventions de nommage▲
Charles Simonyi a écrit le détail de ces conventions et nous allons ici résumer son propos et voir dans quelle mesure vous pouvez adapter ces conventions de création des noms dans un programme à votre langage fétiche. L'application de ces conventions apporte trois avantages majeurs : les avantages inhérents à toute standardisation, une meilleure lisibilité du source et un débogage facilité (surtout en ce qui concerne la chasse aux erreurs de type).
Lorsque l'on est en train de programmer, on doit souvent prendre la décision de créer un nom de variable. Quatre critères principaux vont guider notre choix :
- des critères mnémotechniques : il est important que le programmeur se souvienne des noms qu'il choisit ;
- des critères de lisibilité : les noms ne doivent pas être ésotériques de manière à ce qu'un autre programmeur puisse les appréhender sans problème ;
- des critères de cohérence : les noms ayant des caractéristiques communes doivent se ressembler ;
- des critères de rapidité : il est enfin important de ne pas passer des heures à trouver des noms adéquats (c'est d'ailleurs souvent parce que l'on veut faire cela rapidement que l'on fait n'importe quoi…).
Les conventions que l'on va adopter doivent satisfaire peu ou prou les quatre impératifs que nous venons d'énoncer. L'idée de base de la notation hongroise est de nommer toute donnée d'après son type. Mais cette idée toute simple peut se révéler complexe dans son application. Si deux données supportent des ensembles d'opérations différentes, nous conviendrons qu'elles sont de types différents. Les règles de constitution des noms sont les suivantes :
1) La donnée est nommée d'après son type qui peut être suivi par un qualificateur (c'est-à-dire un terme qui qualifie), le type et le qualificateur devant être séparés, pour des raisons évidentes de lisibilité, par un séparateur qui peut être une barre de soulignement ou bien une différence entre majuscules et minuscules (lig_prem ou bien encore ligPrem) ;
2) Un qualificateur sert à différencier deux données qui sont du même type et qui sont utilisées dans la même unité du programme (programme en entier, procédure, bloc, structure de données…). On peut admettre que parfois plus d'un qualificateur peut être employé dans un nom ;
3) Les types simples sont constitués de mots très courts de manière à ce que les types complexes puissent être constitués à partir de ces derniers.
On peut en principe enrichir le vocabulaire de base (dont nous donnerons la liste plus loin), mais il apparaît comme suffisamment étendu pour satisfaire la majorité des programmeurs.
En ce qui concerne le nom des procédures ou des fonctions, la notion de type est moins pertinente, car une procédure peut ne pas avoir de paramètre et ne renvoyer aucune valeur. Quoi qu'il en soit, on peut recommander de distinguer les procédures des autres noms en les faisant toujours commencer par une majuscule. Si la procédure renvoie une valeur, il faut commencer le nom par le type de cette valeur. L'action de la procédure doit être exprimée par un verbe. On peut si nécessaire ajouter au nom la liste des paramètres.
La liste des types standard telle que Simonyi la définit est la suivante :
pX pointeur sur X
dX différence entre deux instances de type X
cX comptage des instances de type X
mpXY tableau de Y indexé par X (map)
rgX tableau de X (range)
iX indice de tableau rgX
dnX tableau indexé par le type X
eX élément du tableau dnX
grpX groupe de X stockés en file
bX offset relatif à un type X
cbX taille des instances de X en octets
CbX taille des instances de X en mots
Cette liste est complétée par celle des qualificateurs standards :
XFirst premier élément d'un ensemble ordonné de valeurs X
XLast dernier élément d'un ensemble ordonné de valeurs X
XLim stricte limite supérieure d'un ensemble ordonné de valeurs X
XMax stricte limite supérieure pour toutes les valeurs de X
XMac limite supérieure courante pour toutes les valeurs de X
XNil valeur Nil de type X
XT valeur temporaire de X
On trouve de plus les primitives de type :
f drapeau (flag) logique
w mot
ch caractère ASCII
b octet
sz pointeur sur le premier caractère d'une chaîne terminée par un zéro
st pointeur sur une chaîne
À la lecture de ces listes, vous pouvez constater que nous avons pris le parti de ne pas les traduire si bien qu'elles conservent leur caractère anglophone. Vous pouvez également observer que ces listes semblent plutôt s'appliquer à des langages tels que C.
III. Tentative de francisation▲
Par le passé, évoluant dans le milieu du développement xBase, nous avions tenté de proposer une notation hongroise en français qui prenne en compte la spécificité de xBASE.
Voici ce que cela donnait :
III-A. Liste des types▲
b bloc de code
c caractère
d date
f fichier (numéro de handle)
l logique
m mémo
n numérique
o objet
t tableau
v variable associée à un champ
III-B. Liste des qualificateurs▲
Nouv nouveau
Sauv sauvegardé
Temp temporaire
Attr attribut
Tabl tableau
List liste
Coul couleur
Curs curseur
Dbf associé à un fichier DBF
Dbt associé à un fichier DBT
Ntx associé à un fichier NTX
Prem premier
Dern dernier
Fich fichier
Cham champ
Nom nom
Mess message
Enrg enregistrement
Ret valeur de retour
Ecr écran
Chai chaîne de caractères
Haut servent à qualifier les coordonnées d'une boîte ou d'une fenêtre
Gau
Droi
Bas
Lig ligne
Col colonne
X coordonnée de ligne
Y coordonnée de colonne
Max limite supérieure
Min limite inférieure
Un qualificateur ne peut excéder quatre caractères ce qui permet de mixer au moins deux qualificateurs dans un même nom.
III-C. Variables▲
Elles doivent toutes être formées selon la syntaxe suivante :
type + qualificateur
sachant que l'on peut concaténer plusieurs qualificateurs.
tDbf tableau des noms de fichier DBF
tcNom tableau de caractères de noms
nMaxLig coordonnée maximale de ligne
cMessAlert variable caractère de message d'alerte
IV. RVBA▲
Dans leur somme sur VBA intitulée VBA Developper's Handbook (publié chez Sybex), Ken Getz et Mike Gilbert consacrent une annexe d'une vingtaine de pages à la reproduction d'une nouvelle convention pour VBA intitulée Reddick VBA Naming Conventions, du nom de son auteur, Greg Reddick. Bien évidemment, Chales Simonyi est reconnu comme étant à l'origine de cette convention de nommage à laquelle a également participé Stan Leszynski.
Vous trouverez à l'adresse http://www.xoc.net/standards/default.asp la description complète de cette convention d'écriture des identificateurs qui a été complétée depuis peu par une convention pour .NET.
V. Conclusion▲
À travers cet article, nous avons voulu faire réfléchir le programmeur à un aspect qui est trop souvent négligé : la lisibilité des programmes qui, à notre avis, est une des composantes primordiales de la qualité du code. Interrogez autour de vous vos collègues programmeurs sur le temps pris par la maintenance logicielle dans le cycle de vie d'une application et vous verrez qu'il y a lieu de ne pas prendre à la légère cet aspect des choses. Sous prétexte de rentabilité, on ne prend pas assez de temps pour réfléchir à ses outils de travail et à la manière dont on travaille. Cela représente de faibles économies à très court terme : il vaut souvent bien mieux s'arrêter et prendre le temps de penser à ce que l'on fait : cela prend certes du temps, mais on peut espérer que cela rapportera plus tard : c'est ce que l'on appelle un investissement…
Il nous paraîtrait hautement intéressant que cette tribune recueille vos idées en matière de normalisation de code et que le site préconise un standard de style de programmation, en partant notamment de la convention RVBA qui est aujourd'hui largement adoptée par de nombreux programmeurs anglophones. Nous vivons un monde où les idées et les programmes circulent ; il est aujourd'hui de plus en plus rare qu'un programme ne soit lu que par une seule personne. Si l'idée d'un espéranto informatique nous paraît aujourd'hui utopique, force est de reconnaître que l'on peut néanmoins soigner son style et adopter une position commune en la matière. N'oubliez pas cette maxime de Buffon : « Le style, c'est l'homme ! »