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 ! »