Notation hongroise, l'originale

Si vous programmez sur Windows depuis quelque temps, vous connaissez certainement la notation hongroise. C’est une convention où l’on écrit quelques caractères devant chaque nom de variable pour indiquer le type de variable. Par exemple, le nom d’une variable de type int est préfixé de i, un pointeur de p, et un pointeur vers un int de pi. Aujourd’hui, cette pratique n’est pas très bien vue, même chez Microsoft, parce qu’elle est pratiquement inutile et comporte un grand risque d’erreur. J’ai été agréablement surpris cependant quand j’ai appris que cette interprétation n’est qu’un mauvais pli de l’usage original de la notation hongroise telle qu’elle a été inventée à ses débuts.

Voici un extrait de Making Wrong Code Look Wrong (Joel on Software), traduction libre :

Le hongrois d’application était très précieux, spécialement dans le temps du C où le compilateur n’avait pas un système de type très utile.

Mais un jour, quelque chose de mauvais est arrivé.

Le coté obscur s’est emparé de la notation hongroise.

Personne ne sait trop pourquoi ni comment, mais il semblerait que les rédacteurs de documentation dans l’équipe de Windows ont inventé par inadvertance ce que l’on appelera le hongrois système.

Quelqu’un, quelque part, a lu le document de Simonyi, là où il utilise le mot « type, » et a pensé qu’il parlait d’un type, comme une classe, comme dans un système de type, comme la vérification de type faite par le compilateur. Ce n’est pas ça. Il explique très clairement exactement ce qu’il entend par le mot « type, » mais ça n’a pas été suffisant. Le mal était fait.

Le hongrois d’application utilisait des préfixes très utiles, significatifs tel que « ix » pour signifier l’index dans un tableau, « c » pour indiquer un compte, « d » pour la différence entre deux nombres (par exemple « dx » signifiait « largeur ») et ainsi de suite.

Le hongrois système avait des préfixes bien moins utiles, tel que « l » pour le type long et ul pour le type unsigned long et dw pour « double word », qui est, surprise !, un unsigned long. En hongrois système, la seule chose que le préfixe indiquait était le type stockage de la variable.

Donc, en simple, le hongrois d’application est utile pour différencier les données que le compilateur vous laisse mélanger parce qu’elles sont du même type, mais que vous ne devriez pas mélanger. C’est un peu la même analogie que de garder vos unités avec vous en écrivant des formules pour rendre les erreurs plus évidentes.

Mais ça ne s’applique pas qu’au maths…

PHP Markdown utilise une approche similaire

Bien que je ne sois pas certain qu’un suffixe peut se qualifier de notation hongroise, dans PHP Markdown plusieurs chaînes de caractères en ont un : le suffixe _re sur une variable dénote qu’elle contient une expression régulière. Ceci aide à s’assurer qu’aucun caractère n’est passé au parseur d’expression régulière sans être d’abord proprement échappé.

Le résultat final est que c’est très facile de trouver des erreurs. Par exemple, si je vois ceci dans PHP Mardkown, je sais qu’il y a un problème avec la variable $token lorsqu’elle se fait intégrer à une expression régulière sans être d’abord convertie (remarquez l’absence de suffixe _re) :

preg_match('/^(.*?[^`])' . $token . '(?!`)(.*)$/sm', $str, $matches);

Dans ce cas, la solution est d’appeler preg_quote sur $token afin de la rendre sécuritaire pour le parseur d’expression régulière.

C’est intéressant de noter qu’avec les langages qui permettent de définir vos propres types et de surcharger les opérateurs — tel que le C++, lel C# ou le D — vous pourriez définir vos propre types et faire en sorte que le compilateur vous indique vos erreurs. L’effort requis pour la définition de nouveaux types (ainsi que toutes leurs interactions) n’en vaudra cependant peut-être pas la peine comparé à l’utilisation d’une simple notation.