Les gens utilisent-ils les conventions de dénomination hongroises dans le monde réel ?

Question

Cela vaut-il la peine d'apprendre la convention ou est-ce un fléau pour la lisibilité et la maintenabilité ?

Answer 1

Considérant que la plupart des gens qui utilisent Notation hongroise suit la version incomprise, je dirais que c'est plutôt inutile.

Si vous voulez utiliser la définition originale de ce terme, cela peut avoir plus de sens, mais à part cela, c'est surtout du sucre syntaxique.

Si vous lisez le Article de Wikipedia sur le sujet, vous trouverez deux notations contradictoires, Systèmes Notation hongroise y Applications Notation hongroise .

La définition originale, bonne, est la suivante Applications Notation hongroise mais la plupart des gens utilisent l'option Systèmes Notation hongroise .

À titre d'exemple, pensez à préfixer les variables avec l pour longueur, a pour aire et v pour volume.

Avec une telle notation, l'expression suivante prend tout son sens :

int vBox = aBottom * lVerticalSide;

mais ce n'est pas le cas :

int aBottom = lSide1;

Si vous mélangez les préfixes, ils doivent être considérés comme faisant partie de l'équation, et volume = aire * longueur est correct pour une boîte, mais copier une valeur de longueur dans une variable d'aire devrait soulever quelques drapeaux rouges.

Malheureusement, l'autre notation, moins utile, consiste à faire précéder le nom des variables du type de la valeur, comme ceci :

int iLength;
int iVolume;
int iArea;

certaines personnes utilisent n pour nombre, ou i pour entier, f pour flottant, s pour chaîne de caractères, etc.

Le préfixe original était censé être utilisé pour repérer les problèmes dans les équations, mais il s'est transformé en un moyen de rendre le code légèrement plus facile à lire, puisque vous n'avez pas à chercher la déclaration de la variable. Avec les éditeurs intelligents d'aujourd'hui où vous pouvez simplement survoler n'importe quelle variable pour trouver le type complet, et pas seulement une abréviation, ce type de notation hongroise a perdu beaucoup de sa signification.

Mais, vous devez vous faire votre propre opinion. Tout ce que je peux dire, c'est que je n'utilise ni l'un ni l'autre.

---

Modifier Juste pour ajouter un petit avis, bien que je n'utilise pas de Notation hongroise J'utilise un préfixe, et c'est l'underscore. Je préfixe tous les champs privés des classes par un _ et j'écris leurs noms comme je le ferais pour une propriété, en majuscule avec la première lettre en majuscule.

Answer 2

La convention de nommage hongroise peut être utile lorsqu'elle est utilisée correctement. Malheureusement, elle est le plus souvent mal utilisée.

Lire l'article de Joel Spolsky Faire en sorte que le code erroné ait l'air erroné pour une mise en perspective et une justification appropriées.

Essentiellement, la notation hongroise basée sur le type, où les variables sont préfixées avec des informations sur leur type (par exemple, si un objet est une chaîne de caractères, un handle, un int, etc.) est inutile et ne fait qu'ajouter des frais généraux avec très peu d'avantages. Malheureusement, c'est la notation hongroise avec laquelle la plupart des gens sont familiers. Cependant, l'intention de la notation hongroise telle qu'elle est envisagée est d'ajouter des informations sur le "type" de données que la variable contient. Cela vous permet de séparer des types de données d'autres types de données qui ne devraient pas être autorisés à être mélangés, sauf, éventuellement, par un processus de conversion. Par exemple, des coordonnées basées sur des pixels par rapport à des coordonnées dans d'autres unités, ou des entrées utilisateur non sécurisées par rapport à des données provenant de sources sûres, etc.

Voyez les choses ainsi : si vous vous retrouvez à fouiller dans le code pour trouver des informations sur une variable, vous devez probablement adapter votre schéma de dénomination pour contenir ces informations, c'est l'essence même de la convention hongroise.

Notez qu'une alternative à la notation hongroise est d'utiliser plus de classes pour montrer l'intention de l'utilisation des variables plutôt que de s'appuyer partout sur des types primitifs. Par exemple, au lieu d'avoir des préfixes de variables pour les entrées utilisateur non sécurisées, vous pouvez avoir une simple classe d'enveloppe de chaîne pour les entrées utilisateur non sécurisées, et une classe d'enveloppe séparée pour les données sécurisées. Cela a l'avantage, dans les langages fortement typés, d'avoir un partitionnement imposé par le compilateur (même dans les langages moins fortement typés, vous pouvez généralement ajouter votre propre code de déclenchement) mais ajoute une quantité non négligeable de surcharge.

Answer 3

J'utilise toujours la notation hongroise lorsqu'il s'agit d'éléments d'interface utilisateur, où plusieurs éléments d'interface utilisateur sont liés à un objet/valeur particulier, par exemple,

lblFirstName pour l'objet étiquette, txtFirstName pour la zone de texte. Je ne peux absolument pas les nommer tous les deux "FirstName", même si je ne peux pas le faire. que est la préoccupation/responsabilité des deux objets.

Comment les autres abordent-ils la dénomination des éléments de l'interface utilisateur ?

Answer 4

C'est inutile (et distrayant) mais c'est relativement utilisé dans mon entreprise, au moins pour des types comme les ints, les chaînes de caractères, les booléens et les doubles.

Des choses comme sValue , iCount , dAmount o fAmount et bFlag sont partout.

Il était une fois une bonne raison pour cette convention. Maintenant, c'est un cancer.

Answer 5

Je pense que la notation hongroise est une note de bas de page intéressante sur le "chemin" vers un code plus lisible, et si elle est faite correctement, elle est préférable à ne pas la faire.

En disant cela, je préférerais m'en débarrasser et remplacer ça par ceci :

int vBox = aBottom * lVerticalSide;

écrivez ceci :

int boxVolume = bottomArea * verticalHeight;

Nous sommes en 2008. Nous n'avons plus d'écrans à largeur fixe de 80 caractères !

De plus, si vous écrivez des noms de variables beaucoup plus longs que cela, vous devriez de toute façon envisager une refactorisation en objets ou en fonctions.