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

https://stackoverflow.com/questions/5428

08-06-2019
|

Question

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

La solution

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

Si vous souhaitez en utiliser la définition originale, cela peut avoir plus de sens, mais à part cela, il s'agit principalement de sucre syntaxique.

Si vous lisez le Article Wikipédia sur le sujet, vous trouverez deux notations contradictoires, Systèmes de notation hongroise et Applications Notation hongroise.

La bonne définition originale est la Applications Notation hongroise, mais la plupart des gens utilisent le Systèmes de notation hongroise.

À titre d'exemple des deux, envisagez de préfixer les variables avec l pour la longueur, a pour la surface et v pour le 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 = surface * longueur convient pour une boîte, mais copier une valeur de longueur dans une variable de zone devrait déclencher des signaux d'alarme.

Malheureusement, l'autre notation est moins utile, où les gens préfixent les noms de variables avec le type de la valeur, comme ceci :

int iLength;
int iVolume;
int iArea;

certaines personnes utilisent n pour nombre, ou i pour entier, f pour float, s pour chaîne, etc.

Le préfixe d'origine était destiné à être utilisé pour détecter les problèmes dans les équations, mais il a d'une manière ou d'une autre contribué à rendre le code légèrement plus facile à lire puisque vous n'avez pas besoin d'aller chercher la déclaration de 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 son sens.

Mais vous devriez vous faire votre propre opinion.Tout ce que je peux dire, c'est que je n'en utilise pas non plus.

Modifier Juste pour ajouter un bref avis, pendant que je n'utilise pas Notation hongroise, j'utilise un préfixe, et c'est le trait de soulignement.Je préfixe tous les champs privés des classes avec un _ et j'épelle autrement leurs noms comme je le ferais pour une propriété, en majuscule avec la première lettre majuscule.

Autres conseils

La convention de dénomination hongroise peut être utile lorsqu'elle est utilisée correctement, malheureusement elle a tendance à être utilisée à mauvais escient le plus souvent.

Lire l'article de Joel Spolsky Donner l'impression qu'un mauvais code est faux pour une perspective et une justification appropriées.

Essentiellement, la notation hongroise basée sur le type, où les variables sont préfixées par des informations sur leur type (par ex.si un objet est une chaîne, un handle, un int, etc.) est pour la plupart inutile et ne fait généralement qu'ajouter une surcharge avec très peu d'avantages.Malheureusement, c’est la notation hongroise que la plupart des gens connaissent.Cependant, l'objectif de la notation hongroise telle qu'envisagée est d'ajouter des informations sur le « type » de données contenues dans la variable.Cela vous permet de partitionner des types de données à partir d'autres types de données qui ne devraient pas être autorisées à être mélangées, sauf, éventuellement, via un processus de conversion.Par exemple, les coordonnées basées sur les pixels vs.coordonnées dans d'autres unités, ou entrée utilisateur non sécurisée par rapport aux données provenant de sources sûres, etc.

Regardez les choses de cette façon, si vous vous retrouvez à parcourir du code pour trouver des informations sur une variable, vous devrez probablement ajuster votre schéma de dénomination pour contenir ces informations, c'est l'essence de la convention hongroise.

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

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/une valeur particulière, par exemple :

lblFirstName pour l'objet étiquette, txtFirstName pour la zone de texte.Je ne peux certainement pas les appeler tous les deux "Prénom", même si que est la préoccupation/responsabilité des deux objets.

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

C'est inutile (et distrayant) mais est relativement utilisé dans mon entreprise, du moins pour les types comme les entiers, les chaînes, les booléens et les doubles.

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

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

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 effectuée correctement, elle est préférable à ne pas le faire.

En disant cela, je préfère m'en débarrasser, et au lieu de ceci :

int vBox = aBottom * lVerticalSide;

écrire cela:

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 de les refactoriser en objets ou en fonctions.

Désolé de répondre à une question, mais le préfixe des interfaces avec « I » est-il considéré comme une notation hongroise ?Si tel est le cas, alors oui, beaucoup de gens l'utilisent dans le monde réel.Sinon, ignorez cela.

Je vois la notation hongroise comme un moyen de contourner la capacité de nos mémoires à court terme.Selon les psychologues, nous pouvons stocker environ 7 plus ou moins 2 morceaux d'information.Les informations supplémentaires ajoutées en incluant un préfixe nous aident en fournissant plus de détails sur la signification d'un identifiant même sans autre contexte.En d’autres termes, on peut deviner à quoi sert une variable sans voir comment elle est utilisée ou déclarée.Cela peut être évité en appliquant des techniques oo telles que encapsulation et le principe de responsabilité unique.

Je ne sais pas si cela a été étudié empiriquement ou non.Je supposerais que la quantité d'effort augmente considérablement lorsque nous essayons de comprendre des classes avec plus de neuf variables d'instance ou des méthodes avec plus de 9 variables locales.

La portée n'est-elle pas plus importante que le type de nos jours, par ex.

l pour local
un argument
m pour membre
g pour global
etc.

Avec les techniques modernes de refactorisation de l'ancien code, la recherche et le remplacement d'un symbole parce que vous avez modifié son type sont fastidieux, le compilateur détectera les changements de type, mais ne détectera souvent pas une utilisation incorrecte de la portée, des conventions de dénomination sensées sont utiles ici.

Quand je vois des discussions en hongrois, je suis heureux de voir les gens réfléchir sérieusement à la manière de rendre leur code plus clair et de rendre les erreurs plus visibles.C'est exactement ce que nous devrions tous faire !

Mais n’oubliez pas que vous disposez d’outils puissants en plus de la dénomination.

Méthode d'extraction Si vos méthodes deviennent si longues que vos déclarations de variables défilent en haut de l'écran, envisagez de réduire la taille de vos méthodes.(Si vous avez trop de méthodes, envisagez une nouvelle classe.)

Frappe forte Si vous constatez que vous prenez code postals stockés dans une variable entière et en les affectant à un pointure variable entière, envisagez de créer une classe pour les codes postaux et une classe pour la pointure des chaussures.Votre bug sera alors détecté au moment de la compilation, au lieu de nécessiter une inspection minutieuse par un humain.Lorsque je fais cela, je trouve généralement un tas de logiques spécifiques au code postal et à la pointure des chaussures que j'ai dispersées autour de mon code, que je peux ensuite intégrer dans mes nouvelles classes.Tout à coup, tout mon code devient plus clair, plus simple et protégé de certaines classes de bugs.Ouah.

Pour résumer:oui, réfléchissez bien à la façon dont vous utilisez les noms dans le code pour exprimer clairement vos idées, mais regardez également les autres outils OO puissants auxquels vous pouvez faire appel.

Je n'utilise pas un sens très strict de la notation hongroise, mais je me retrouve à l'utiliser avec parcimonie pour certains objets personnalisés courants pour aider à les identifier, et j'ai également tendance à préfixer les objets de contrôle gui avec le type de contrôle qu'ils sont.Par exemple, labelFirstName, textFirstName et ButtonSubmit.

J'utilise le nom hongrois pour les éléments de l'interface utilisateur tels que les boutons, les zones de texte et les étiquettes.Le principal avantage est le regroupement dans la fenêtre contextuelle Visual Studio Intellisense.Si je veux accéder à mes étiquettes, je commence simplement à taper lbl....et Visual Studio proposera toutes mes étiquettes, joliment regroupées.

Cependant, après avoir fait de plus en plus de choses avec Silverlight et WPF, en exploitant la liaison de données, je ne nomme même plus tous mes contrôles, car je n'ai pas besoin de les référencer à partir du code-behind (puisqu'il n'y a vraiment plus de code-behind). ;)

Ce qui ne va pas, c'est de mélanger les normes.

Ce qui est juste, c'est de s'assurer que tout le monde fasse la même chose.

int Box = iBottom * nVerticleSide

Le préfixe d'origine était destiné à être utilisé pour repérer les problèmes dans les équations, mais a en quelque sorte dévolu pour rendre le code légèrement plus facile à lire car vous n'avez pas à aller chercher la déclaration 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 son sens.

Je romps un peu avec l'habitude, mais le préfixe avec le type peut être utile en JavaScript qui n'a pas de typage de variable fort.

Lorsque j'utilise une langue typée dynamiquement, j'utilise occasionnellement Apps hongrois.Pour les langages typés statiquement, je ne le fais pas.Voir mon explication dans l'autre fil.

La notation hongroise est inutile dans les langues de type sécurisé.par exemple.Un préfixe courant que vous verrez dans l'ancien code Microsoft est "lpsz", ce qui signifie "long pointeur vers une chaîne terminée par zéro".Depuis le début des années 1700, nous n'avons pas utilisé d'architectures segmentées où existent des pointeurs courts et longs, la représentation de chaîne normale en C++ se termine toujours par un zéro et le compilateur est de type sécurisé, nous ne pouvons donc pas appliquer d'opérations sans chaîne au chaîne.Par conséquent, aucune de ces informations n’est réellement utile à un programmeur – il s’agit simplement de plus de saisie.

Cependant, j'utilise une idée similaire :préfixes qui clarifient le usage d'une variable.Les principaux sont :

m = membre
c = const
s = statique
v = volatile
p = pointeur (et pp=pointeur vers pointeur, etc.)
i = index ou itérateur

Ceux-ci peuvent être combinés, donc une variable membre statique qui est un pointeur serait "mspName".

Où sont-ils utiles ?

Lorsque l'utilisation est importante, c'est une bonne idée de rappeler constamment au programmeur qu'une variable est (par exemple) un volatile ou un pointeur.
Le déréférencement du pointeur me faisait la tête jusqu'à ce que j'utilise le préfixe p.Maintenant, il est vraiment facile de savoir quand vous avez un objet (Orange), un pointeur vers un objet (pOrange) ou un pointeur vers un pointeur vers un objet (ppOrange).Pour déréférencer un objet, il suffit de mettre un astérisque devant lui pour chaque p de son nom.Affaire résolue, plus de bugs de ref !
Dans les constructeurs, je trouve généralement qu'un nom de paramètre est identique au nom d'une variable membre (par ex.taille).Je préfère utiliser "MSIze = taille;" que "size = thesize" ou "this.size = taille".C'est aussi beaucoup plus sûr :Je n'utilise pas accidentellement "size = 1" (définition du paramètre) alors que je voulais dire "mSize = 1" (définition du membre)
Dans les boucles, mes variables d'itérateur sont toutes des noms significatifs.La plupart des programmeurs utilisent "i" ou "index" et doivent ensuite inventer de nouveaux noms dénués de sens ("j", "index2") lorsqu'ils veulent une boucle interne.J'utilise un nom significatif avec un préfixe i (iHospital, iWard, iPatient), donc je sais toujours ce qu'un itérateur itère.
Dans les boucles, vous pouvez mélanger plusieurs variables liées en utilisant le même nom de base avec des préfixes différents :Orange orange = pOrange[iOrange];Cela signifie également que vous ne faites pas d'erreurs d'indexation de tableau (pApple[i] semble correct, mais écrivez-le sous la forme pApple[iOrange] et l'erreur est immédiatement évidente).
De nombreux programmeurs utiliseront mon système sans le savoir :en ajoutant un long suffixe comme "Index" ou "Ptr" - il n'y a aucune bonne raison d'utiliser une forme plus longue qu'un seul caractère à mon humble avis, j'utilise donc "i" et "p".Moins de frappe, plus cohérent, plus facile à lire.

Il s'agit d'un système simple qui ajoute des informations significatives et utiles au code et élimine la possibilité de nombreuses erreurs de programmation simples mais courantes.

Je travaille pour IBM depuis 6 mois et je ne l'ai vu nulle part (Dieu merci parce que je déteste ça.) Je vois soit camelCase, soit c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Cela dépend de votre langue et de votre environnement.En règle générale, je ne l'utiliserais pas, à moins que l'environnement de développement dans lequel vous vous trouvez rende difficile la recherche du type de variable.

Il existe également deux types différents de notation hongroise.Voir l'article de Joël.Je ne le trouve pas (ses noms ne permettent pas vraiment de les trouver facilement), quelqu'un a-t-il un lien vers celui dont je parle ?

Modifier:Wedge a l'article dont je parle dans son message.

Forme originale (La bonne notation hongroise :)) où le préfixe signifie le type (c'est-à-direlongueur, quantité) de la valeur stockée par variable est OK, mais pas nécessaire dans tous les types d'applications.

La forme populaire (The Wrong Hongrois Notation) où le préfixe signifie type (String, int) est inutile dans la plupart des langages de programmation modernes.

Surtout avec des noms dénués de sens comme strA.Je ne comprends pas que nous, les gens, utilisions des noms dénués de sens avec de longs préfixes qui ne donnent rien.

J'utilise un type basé (Systems HN) pour les composants (par exemple editFirstName, lblStatus, etc.) car cela améliore le fonctionnement de la saisie semi-automatique.

J'utilise parfois App HN pour les variables où les informations de type sont suffisantes.C'est-à-dire que fpX indique une variable à pointe fixe (type int, mais ne peut pas être mélangée et mise en correspondance avec un int), rawInput pour les chaînes utilisateur qui n'ont pas été validées, etc.

Étant un programmeur PHP où il est très vaguement typé, je ne me fais pas un devoir de l'utiliser.Cependant, j'identifierai occasionnellement quelque chose comme un tableau ou comme un objet en fonction de la taille du système et de la portée de la variable.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow