Quel est l'avantage de ne pas utiliser la notation hongroise?
L'une des choses avec lesquelles je lutte n'est pas d'utiliser la notation hongroise. Je ne veux pas devoir aller à la définition de variable juste pour voir de quel type il s'agit. Quand un projet prend de l'ampleur, c'est bien de pouvoir regarder une variable préfixée par 'bool' et savoir qu'il cherche vrai/faux au lieu d'un /1 valeur.
Je fais également beaucoup de travail dans SQL Server. Je préfixe mes procédures stockées avec 'sp' et mes tables avec 'tbl', sans parler de toutes mes variables dans la base de données respectivement.
Je vois partout que personne ne veut vraiment utiliser la notation hongroise, au point où ils l'évitent. Ma question est, quel est l'avantage de ne pas utiliser la notation hongroise, et pourquoi la majorité des développeurs l'évitent-ils comme la peste?
Parce que son intention originale (voir http://www.joelonsoftware.com/articles/Wrong.html et http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) a été mal compris et il a été (ab) utilisé pour aider les gens à se rappeler de quel type est une variable lorsque la langue qu'ils utilisent n'est pas typée statiquement. Dans n'importe quel langage de type statique, vous n'avez pas besoin du ballast ajouté de préfixes pour vous dire de quel type est une variable. Dans de nombreux langages de script non typés, cela peut aider, mais il a souvent été utilisé à mauvais escient au point de devenir totalement lourd. Malheureusement, au lieu de revenir à l'intention originale de la notation hongroise, les gens viennent d'en faire une de ces choses "mauvaises" que vous devriez éviter.
La notation hongroise en bref était destinée à préfixer les variables avec une certaine sémantique. Par exemple, si vous avez des coordonnées d'écran (gauche, haut, droite, bas), vous préfixez les variables avec des positions d'écran absolues avec "abs" et les variables avec des positions relatives à une fenêtre avec "rel ". De cette façon, il serait évident pour tout lecteur lorsque vous avez passé une coordonnée relative à une méthode nécessitant des positions absolues.
mise à jour (en réponse au commentaire de delnan)
À mon humble avis, la version abusée doit être évitée comme la peste parce que:
- cela complique la dénomination. Lorsque (ab) utilise la notation hongroise, il y aura toujours des discussions sur la spécificité des préfixes. Par exemple:
listboxXYZouMyParticularFlavourListBoxXYZ. - elle allonge les noms de variable sans aider à comprendre à quoi sert la variable.
- cela défait en quelque sorte l'objet de l'exercice lorsque, afin d'éviter de longs préfixes, ceux-ci sont raccourcis en abréviations et vous avez besoin d'un dictionnaire pour savoir ce que signifie chaque abréviation. Un
uiest-il un entier non signé? une interface comptée non référencée? quelque chose à voir avec les interfaces utilisateur? Et ces choses peuvent devenir longues . J'ai vu des préfixes de plus de 15 caractères apparemment aléatoires qui sont censés transmettre le type exact de la var mais qui ne font que mystifier. - il devient rapidement obsolète. Lorsque vous changez le type d'une variable, les gens invariablement (lol) oublient de mettre à jour le préfixe pour refléter le changement, ou délibérément ne le mettez pas à jour car cela déclencherait des changements de code partout où la var est utilisée ...
- cela complique le fait de parler de code car "@g". a déclaré: Les noms de variable avec la notation hongroise sont généralement difficiles à prononcer. Cela empêche la lisibilité et la discussion du code, car vous ne pouvez pas "dire" aucun des noms.
- ... beaucoup plus que je ne me souviens pas pour le moment. Peut-être parce que j'ai eu le plaisir de ne pas avoir à faire face à la notation hongroise abusée depuis longtemps ...
La notation hongroise est un anti-modèle de dénomination dans les environnements de programmation modernes et une forme de tautologie .
Il répète inutilement des informations sans aucun avantage ni frais de maintenance supplémentaires. Que se passe-t-il lorsque vous changez votre int en un type différent comme long, vous devez maintenant rechercher et remplacer l'intégralité de votre base de code pour renommer toutes les variables ou elles sont maintenant sémantiquement incorrectes, ce qui est pire que si vous n'avez pas dupliqué le type dans le nom.
Il viole le principe DRY. Si vous devez préfixer vos tables de base de données avec une abréviation pour vous rappeler qu'il s'agit d'une table, alors vous ne nommez certainement pas vos tables sémantiquement de manière suffisamment descriptive. Il en va de même pour toutes les autres choses avec lesquelles vous faites cela. Il s'agit simplement d'une saisie supplémentaire et de travailler sans aucun gain ni avantage avec un environnement de développement moderne.
Wikipedia a une liste d'avantages et d'inconvénients de la notation hongroise et peut donc probablement fournir la réponse la plus complète à cette question. Les opinions notables sont également une lecture assez intéressante.
L'avantage de de ne pas utiliser la notation hongroise est simplement d'éviter ses inconvénients:
La notation hongroise est redondante lorsque la vérification de type est effectuée par le compilateur. Les compilateurs pour les langues fournissant une vérification de type garantissent que l'utilisation d'une variable est cohérente avec son type automatiquement; les contrôles à l'œil sont redondants et sujets à des erreurs humaines.
Tous les environnements de développement intégrés modernes affichent des types variables à la demande et signalent automatiquement les opérations qui utilisent des types incompatibles, ce qui rend la notation largement obsolète.
La notation hongroise devient confuse lorsqu'elle est utilisée pour représenter plusieurs propriétés, comme dans
a_crszkvc30LastNameCol: Un argument de référence constant, contenant le contenu d'une colonne de base de donnéesLastNamede typevarchar(30)qui fait partie de la clé primaire de la table.Cela peut entraîner une incohérence lorsque le code est modifié ou porté. Si le type d'une variable est modifié, soit la décoration sur le nom de la variable sera incohérente avec le nouveau type, soit le nom de la variable doit être changé. Un exemple particulièrement bien connu est le type standard
WPARAMet le paramètre formelwParamqui l'accompagne dans de nombreuses déclarations de fonction système Windows. Le "w" signifie "Word", où "Word" est la taille native de Word de l'architecture matérielle de la plate-forme. Il s'agissait à l'origine d'un type 16 bits sur les architectures Word 16 bits, mais a été changé en 32 bits sur les architectures Word 32 bits, ou en type 64 bits sur les architectures Word 64 bits dans les versions ultérieures du système d'exploitation tout en conservant son nom d'origine (son vrai type sous-jacent estUINT_PTR, c'est-à-dire un entier non signé suffisamment grand pour contenir un pointeur). L'impédance sémantique, et donc la confusion et l'incohérence des programmeurs de plate-forme à plate-forme, repose sur l'hypothèse que "w" signifie 16 bits dans ces différents environnements.La plupart du temps, connaître l'utilisation d'une variable implique de connaître son type. De plus, si l'utilisation d'une variable n'est pas connue, elle ne peut pas être déduite de son type.
La notation hongroise réduit fortement les avantages d'utiliser des éditeurs de code riches en fonctionnalités qui prennent en charge la complétion sur les noms de variables, car le programmeur doit d'abord saisir le spécificateur de type entier.
Il rend le code moins lisible, en masquant le but de la variable avec des préfixes de type et de portée inutiles.
Les informations de type supplémentaires peuvent remplacer insuffisamment des noms plus descriptifs. Par exemple.
sDatabasene dit pas au lecteur ce que c'est.databaseNamepourrait être un nom plus descriptif.Lorsque les noms sont suffisamment descriptifs, les informations de type supplémentaires peuvent être redondantes. Par exemple.
firstNameest très probablement une chaîne. Donc, le nommersFirstNamene fait qu'ajouter de l'encombrement au code.
Je n'utilise pas moi-même cette notation, car je n'aime pas le bruit technique inutile. Je sais presque toujours de quel type je traite et je veux un langage propre dans mon modèle de domaine, mais j'écris principalement dans des langues statiquement et fortement typées.
En tant que problème spécifique à MS SQL Server:
Toutes les procédures stockées préfixées par 'sp_' sont d'abord recherchées dans la base de données Master plutôt que celle dans laquelle elles sont créées. Cela entraînera un retard dans l'exécution de la procédure stockée.
IMO le plus grand avantage de ne pas utiliser le hongrois est le fait qu'il vous oblige à utiliser des noms significatifs . Si vous nommez correctement les variables, vous devez immédiatement savoir de quel type il s'agit ou être capable de le déduire assez rapidement dans n'importe quel système bien conçu. Si vous devez vous fier à str ou bln ou pire à tous les préfixes obj pour savoir de quel type est une variable, je dirais que cela indique un problème de dénomination - soit une mauvaise variable les noms en général ou trop génériques pour donner un sens.
Ironiquement, par expérience personnelle, le principal scénario que j'ai vu utiliser le hongrois est soit une programmation "cargo-culte" (c'est-à-dire qu'un autre code l'utilise, alors continuons de l'utiliser simplement parce que) ou dans VB.NET pour contourner le fait que la langue est insensible à la casse (par exemple Person oPerson = new Person parce que vous ne pouvez pas utiliser Person person = new Person et Person p = new Person est trop vague); J'ai également vu préfixer "le" ou "mon" à la place (comme dans Person thePerson = new Person ou le plus laid Person myPerson = new Person), dans ce cas particulier.
J'ajouterai le seulement fois où j'utilise le hongrois a tendance à être pour les contrôles ASP.NET et c'est vraiment une question de choix. Je trouve très moche de taper TextBoxCustomerName ou CustomerNameTextBox par rapport au simple txtCustomerName, mais même cela semble "sale". Je pense que une sorte de convention de dénomination devrait être utilisée pour les contrôles car il peut y avoir plusieurs contrôles qui affichent les mêmes données.
Je vais me concentrer uniquement sur SQL Server puisque vous l'avez mentionné. Je ne vois aucune raison de mettre "tbl" devant une table. Vous pouvez simplement regarder n'importe quel code tSQL et distinguer une table par la façon dont elle est utilisée. Vous ne feriez jamais Select from stored_procedure. Ou Select from table(with_param) comme vous le feriez avec une UDF ou Execute tblTableOrViewName Comme une procédure stockée.
Les tableaux peuvent être confondus avec une vue, mais en ce qui concerne leur utilisation; il n'y a pas de différence, alors à quoi ça sert? La notation hongroise peut vous faire gagner du temps dans la recherche dans SSMS (sous table ou vues?), Mais c'est tout.
Les variables peuvent présenter un problème, mais elles doivent être déclarées et vraiment, à quelle distance de votre déclaration declare prévoyez-vous d'utiliser une variable? Faire défiler quelques lignes ne devrait pas être si grave, sauf si vous écrivez de très longues procédures. Ce peut être une bonne idée de casser un peu le long code.
Ce que vous décrivez est une douleur, mais la solution de notation hongroise ne résout pas vraiment le problème. Vous pouvez consulter le code de quelqu'un d'autre et constater que le type de variable peut être modifié, ce qui nécessite désormais une modification du nom de la variable. Encore une chose à oublier. Et si j'utilise un VarChar, vous devrez quand même regarder l'instruction declare pour connaître la taille. Les noms descriptifs vous permettront probablement d'aller plus loin. @PayPeriodStartDate s'explique assez bien.
À ma façon de voir les choses, la notation hongroise est un coup de pouce pour contourner un système de caractères insuffisamment puissant. Dans les langages qui vous permettent de définir vos propres types, il est relativement trivial de créer un nouveau type qui code le comportement que vous attendez. Dans le discours de Joel Spolsky sur la notation hongroise, il donne un exemple d'utilisation pour détecter d'éventuelles attaques XSS en indiquant qu'une variable ou une fonction est soit dangereuse (nous) ou sûre (s), mais cela dépend toujours du programmeur pour vérifier visuellement. Si vous disposez à la place d'un système de type extensible, vous pouvez simplement créer deux nouveaux types, UnsafeString et SafeString, puis les utiliser comme il convient. En prime, le type d'encodage devient:
SafeString encode(UnsafeString)
et à court d'accéder aux éléments internes de UnsafeString ou d'utiliser d'autres fonctions de conversion devient le seul moyen de passer d'un UnsafeString à un SafeString. Si toutes vos fonctions de sortie ne prennent alors que des instances de SafeString, il devient impossible de sortir une chaîne non échappée [des manigances à nu avec des conversions telles que StringToSafeString (someUnsafeString.ToString ())].
Il devrait être évident pourquoi permettre au système de type de vérifier la validité de votre code est supérieur à essayer de le faire à la main, ou peut-être à l'œil dans ce cas.
Dans un langage tel que C, bien sûr, vous êtes foutu qu'un int est un int est un int, et vous ne pouvez pas faire grand-chose à ce sujet. Vous pouvez toujours jouer à des jeux avec des structures, mais c'est discutable, que ce soit une amélioration ou non.
Quant à l'autre interprétation de la notation hongroise, I.E. préfixer avec le type de la variable, c'est tout simplement stupide et encourage les pratiques paresseuses comme nommer les variables uivxwFoo au lieu de quelque chose de significatif comme countOfPeople.
Une autre chose à ajouter est que, quelles abréviations utiliseriez-vous pour un framework entier comme .NET? Oui, il est si simple de se rappeler que btn représente un bouton et txt représente une zone de texte. Mais que pensez-vous de quelque chose comme StringBuilder? strbld? Qu'en est-il de CompositeWebControl? Utilisez-vous quelque chose comme ceci:
CompositeWebControl comWCMyControl = new CompositeWebControl();
L'une des inefficacités de la notation hongroise était que, en ayant des cadres de plus en plus grands, elle s'est avérée non seulement ne pas ajouter d'avantages supplémentaires, mais aussi ajouter plus de complexité aux développeurs, car ils devaient maintenant apprendre de plus en plus les préfixes non standard.
La notation hongroise est presque complètement inutile dans une langue typée statiquement. C'est une fonction de base IDE pour afficher le type d'une variable en plaçant la souris dessus ou par d'autres moyens; de plus, vous pouvez voir quel est le type en regardant quelques lignes là où il était) déclaré, s'il n'y a pas d'inférence de type. L'intérêt de l'inférence de type est de ne pas faire répéter le bruit du type partout, donc la notation hongroise est généralement considérée comme une mauvaise chose dans les langues avec l'inférence de type.
Dans les langues typées dynamiquement, cela peut parfois aider, mais pour moi, cela semble unidiomatique. Vous avez déjà abandonné vos fonctions étant limitées à des domaines/domaines de codage exacts; si toutes vos variables sont nommées avec la notation hongroise, alors vous reproduisez simplement ce qu'un système de type vous aurait donné. Comment exprimez-vous une variable polymorphe qui peut être un entier ou une chaîne en notation hongroise? "IntStringX"? "IntOrStringX"? Le seul endroit où j'ai jamais utilisé la notation hongroise était dans le code d'assemblage, car j'essayais de récupérer ce que j'obtiendrais si j'avais un système de type, et c'était la première chose que je codais.
Quoi qu'il en soit, peu m'importe ce que les gens nomment leurs variables, le code sera probablement toujours aussi incompréhensible. Les développeurs perdent trop de temps sur des choses comme le style et les noms de variables, et à la fin de la journée, vous obtenez toujours une tonne de bibliothèques avec des conventions complètement différentes dans votre langue. Je suis en train de développer un langage symbolique (c'est-à-dire non basé sur du texte) où il n'y a pas de noms de variables, seulement des identificateurs uniques et des noms suggérés pour les variables (mais la plupart des variables n'ont toujours pas de nom suggéré car il n'existe tout simplement pas) un nom raisonnable pour eux); lors de l'audit de code non fiable, vous ne pouvez pas dépendre des noms de variables.
Comme d'habitude dans un tel cas, je posterai une réponse avant de lire les réponses des autres participants.
Je vois trois "bugs" dans votre vision:
1) Si vous voulez connaître le type d'une variable/paramètre/attribut/colonne, vous pouvez survoler votre souris ou cliquer dessus et elle s'affichera, dans la plupart des IDE modernes. Je ne sais pas quels outils vous utilisez, mais la dernière fois j'ai été forcé de travailler dans un environnement qui ne fournissait pas cette fonctionnalité était au 20ème siècle, le langage était COBOL, oups non c'était Fortran, et mon patron ne comprenait pas pourquoi je suis parti.
2/Les types peuvent changer au cours du cycle de développement. Un entier 32 bits peut devenir un entier 64 bits à un moment donné, pour de bonnes raisons qui n'avaient pas été détectées au début du projet. Donc, renommer intX en longX ou le laisser avec un nom qui pointe vers le mauvais type est un mauvais karma.
3) Ce que vous demandez, c'est en fait une redondance. La redondance n'est pas un très bon modèle de conception ou une habitude. Même les humains sont réticents à trop de redondance. Même les humains sont réticents à trop de redondance.
Je crois que le besoin urgent de hongrois est un symptôme .
Un symptôme de trop de variables globales ... ou d'avoir des fonctions trop longues pour être maintenable .
Si votre définition de variable n'est pas en vue, vous avez généralement des problèmes.
Et si vos fonctions ne suivent pas une convention mémorable , là encore, gros problème.
C'est ... à peu près la raison pour laquelle de nombreux lieux de travail se précipitent, je suppose.
Il est originaire de langues qui nécessaires it.
Aux heures de variable globale bonanza . (faute d'alternatives)
Cela nous a bien servi.
La seule véritable utilisation que nous en avons aujourd'hui est celle Joel Spolsky .
Pour suivre certains attributs particuliers de la variable, comme son sécurité.
( par exemple “La variable safeFoobar a-t-elle un feu vert à injecter dans une requête SQL?
- Comme on l'appelle safe, oui ”)
Certaines autres réponses ont parlé des fonctionnalités de l'éditeur qui ont aidé à voir le type d'une variable lorsque vous la survolez. À mon avis, ceux-ci sont également un peu problématiques pour l'intégrité du code . Je pense qu'ils étaient uniquement destinés à la refactorisation , ainsi que de nombreuses autres fonctionnalités (comme le pliage de fonctions) et ne devraient pas être utilisés sur le nouveau code.
Je pense que les raisons de ne pas utiliser la notation hongroise ont été bien couvertes par d'autres affiches. Je suis d'accord avec leurs commentaires.
Avec les bases de données, j'utilise la notation hongroise pour les objets DDL qui sont rarement utilisés dans le code, mais qui autrement entreraient en collision dans les espaces de noms. Cela revient principalement à préfixer les index et les contraintes nommées avec leur type (PK, UK, FK et IN). Utilisez une méthode cohérente pour nommer ces objets et vous devriez pouvoir exécuter certaines validations en interrogeant les métadonnées.
Disons que nous avons une méthode comme celle-ci (en C #):
int GetCustomerCount()
{
// some code
}
Maintenant, dans le code, nous l'appelons comme ceci:
var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;
Le int ne nous dit pas grand-chose. Le simple fait que quelque chose soit un int ne nous dit pas ce qu'il contient. Supposons maintenant, à la place, nous l'appelons comme ceci:
var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;
Nous pouvons maintenant voir quel est le but de la variable. Serait-ce important si nous savons que c'est un int?
Le but initial du hongrois, cependant, était de vous faire faire quelque chose comme ceci:
var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;
C'est très bien tant que vous savez ce que c signifie. Mais il faudrait avoir une table standard de préfixes, et tout le monde devrait les connaître, et toute nouvelle personne devrait les apprendre pour comprendre votre code. Alors que customerCount ou countOfCustomers est assez évident à première vue.
Le hongrois avait une utilité dans VB avant Option Strict On existait, car dans VB6 et versions antérieures (et dans VB .NET avec Option Strict Off) VB contraindrait les types, vous pouvez donc faire ceci:
Dim someText As String = "5"
customerCount = customerCount + someText
C'est mauvais, mais le compilateur ne vous le dirait pas. Donc, si vous utilisiez le hongrois, au moins vous auriez un indicateur de ce qui se passait:
Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText // that doesn't look right!
Dans .NET, avec la saisie statique, ce n'est pas nécessaire. Et le hongrois était trop souvent utilisé comme substitut à une bonne appellation. Oubliez le hongrois et choisissez plutôt de bons noms.
la raison pour laquelle il est évité est à cause des systèmes hongrois qui violent DRY (le préfixe est exactement le type que le compilateur et (un bon) IDE peut dériver)
applications hongrois O.T.O.H. préfixes avec tiliser de la variable (c'est-à-dire que scrxMouse est une coordonnée x à l'écran, cela peut être un type int, court, long ou même personnalisé (les typedefs vous permettront même de le changer facilement))
la mauvaise compréhension des systèmes est ce qui a détruit le hongrois comme meilleure pratique
Le seul endroit où j'utilise encore régulièrement des suffixes hongrois ou analogues est dans des contextes où les mêmes données sémantiques sont présentes sous deux formes différentes, comme la conversion de données. Cela peut être dans les cas où il existe plusieurs unités de mesure, ou lorsqu'il existe plusieurs formes (par exemple, la chaîne "123" et l'entier 123).
Je trouve les raisons données ici pour ne pas l'utiliser convaincantes de ne pas imposer le hongrois aux autres, mais seulement légèrement suggestive, pour décider de votre propre pratique.
Le code source d'un programme est une interface utilisateur à part entière - affichant des algorithmes et des métadonnées pour le responsable - et la redondance dans les interfaces utilisateur est une vertu, pas un péché . Voir, par exemple, les images dans " The Design of Everyday Things ", et regardez les portes étiquetées "Push" qui ressemblent à vous les tirez, et aux robinets de bière les opérateurs ont piraté l'important nucléaire contrôle du réacteur parce que "planer sur eux dans l'IDE" n'était pas assez bon.
Le "juste survoler dans un IDE" n'est pas pas une raison de ne pas utiliser le hongrois - seulement une raison certains les gens pourraient ne pas le trouver utile. Votre kilométrage peut différer.
L'idée que le hongrois impose une charge de maintenance importante lorsque les types de variables changent est stupide - à quelle fréquence changez-vous les types de variables? En outre, renommer des variables est facile:
Utilisez simplement le IDE pour renommer toutes les occurrences. Gander, répondant à Goose
Si le hongrois vous aide vraiment à récupérer rapidement un morceau de code et à le maintenir de manière fiable, utilisez-le. Sinon, non. Si d'autres personnes vous disent que vous vous trompez au sujet de votre propre expérience, je dirais que ce sont probablement elles qui se trompent.
J'ai trouvé pas mal de bons arguments contre, mais un que je n'ai pas vu: l'ergonomie.
Autrefois, quand vous n'aviez que string, int, bool et float, les caractères sibf auraient suffi. Mais avec string + short, les problèmes commencent. Utilisez le nom entier pour le préfixe ou str_name pour la chaîne? (Alors que les noms sont presque toujours des chaînes - n'est-ce pas?) Qu'est-ce qui se passe avec une classe Street? Les noms s'allongent de plus en plus et même si vous utilisez CamelCase, il est difficile de dire où se termine le préfixe de type et où commence le nom de variable.
BorderLayout boderLayoutInnerPanel = new BorderLayout ();
panelInner.addLayout (borderLayoutInnerPanel);
D'accord - vous pouvez utiliser des soulignements, si vous ne les utilisez pas déjà pour autre chose, ou utiliser CamelCase si vous avez utilisé des soulignements aussi longtemps:
BorderLayout boderLayout_innerPanel = new BorderLayout ();
panel_inner.addLayout (borderLayout_innerPanel);
Border_layout boder_layoutInner_panel = new Border_layout ();
panelInner.add_layout (border_layoutInner_panel);
C'est monstrueux et si vous le faites en conséquence, vous aurez
for (int iI = 0; iI < iMax-1; ++iI)
for (int iJ = iI; iJ < iMax; ++iMax)
int iCount += foo (iI, iJ);
Soit vous finirez par utiliser des préfixes inutiles pour les cas triviaux, comme les variables de boucle ou count. Quand avez-vous récemment utilisé un short ou un long pour un compteur? Si vous faites des exceptions, vous perdrez souvent du temps, pensant avoir besoin d'un préfixe ou non.
Si vous avez beaucoup de variables, elles sont normalement regroupées dans un navigateur d'objets qui fait partie de votre IDE. Maintenant, si 40% commencent par i_ pour int, et 40% avec s_ pour chaîne, et qu'ils sont triés par ordre alphabétique, il est difficile de trouver la partie significative du nom.