Pourquoi ne devrais-je pas utiliser "Notation hongroise"?
Je sais à quoi le hongrois se réfère - donner des informations sur une variable, un paramètre ou un type en tant que préfixe de son nom. Tout le monde semble être enragé contre elle, même si dans certains cas cela semble être une bonne idée. Si je pense que des informations utiles sont communiquées, pourquoi ne devrais-je pas les mettre là où elles sont disponibles?
Voir aussi: Est-ce que les gens utilisent les conventions de nommage hongroises dans le monde réel?
La plupart des gens utilisent la notation hongroise de manière incorrecte et obtiennent des résultats erronés.
Lisez cet excellent article de Joel Spolsky: Faire en sorte que le code soit faux .
En bref, la notation hongroise où vous préfixez vos noms de variables avec leur type (chaîne) (systèmes hongrois) est mauvaise car elle est inutile.
Notation hongroise telle que voulue par son auteur où vous préfixez le nom de la variable avec son kind (en utilisant l'exemple de Joel: chaîne sécurisée ou chaîne non sécurisée), ainsi appelée Apps Hungarian a ses utilisations et est toujours utile.
vUsing adj La notation hongroise a rendu difficile la lecture de ncode adj.
Joel a tort, et voici pourquoi.
Cette information "d'application" dont il parle devrait être encodée dans le système de types. Ne renversez pas les noms de variables pour vous assurer de ne pas transmettre de données non sécurisées à des fonctions nécessitant des données sécurisées. Vous devriez en faire une erreur de type, de sorte que c'est impossible de le faire. Toutes les données non sécurisées doivent avoir un type marqué comme non sécurisé, afin qu’elles ne puissent tout simplement pas être transmises à une fonction sécurisée. Pour passer de dangereux à sûrs, le traitement doit être effectué avec une sorte de fonction de désinfection.
Beaucoup de choses que Joel appelle "sortes" ne sont pas des sortes; ce sont en fait des types.
Cependant, ce qui manque à la plupart des langues, c'est un système de types suffisamment expressif pour imposer ce type de distinction. Par exemple, si C avait une sorte de "typedef fort" (où le nom de typedef comportait toutes les opérations du type de base, mais n'était pas convertible en celui-ci), beaucoup de ces problèmes disparaîtraient. Par exemple, si vous pouviez dire, strong typedef std::string unsafe_string; pour introduire un nouveau type unsafe_string qui ne peut pas être converti en std :: string (et peut donc participer à la résolution de surcharge, etc. etc.), nous n’aurions donc pas besoin de préfixes idiots.
Ainsi, l'affirmation centrale selon laquelle le hongrois concerne des choses qui ne sont pas des types est fausse. Il est utilisé pour les informations de type. Des informations de type plus riches que les informations de type C traditionnelles, certainement; c'est une information de type qui code une sorte de détail sémantique pour indiquer le but des objets. Mais il s’agit toujours d’informations de type, et la solution appropriée a toujours été de les encoder dans le système de types. Le coder dans le système de types est de loin le meilleur moyen d’obtenir une validation et une application correctes des règles. Les noms de variables ne coupent tout simplement pas la moutarde.
En d’autres termes, l’objectif ne devrait pas être de "faire en sorte que le mauvais code soit erroné pour le développeur". Il devrait être "faire en sorte que le mauvais code paraisse faux au compilateur".
Je pense que cela encombrerait massivement le code source.
De plus, cela ne vous rapporte pas beaucoup dans un langage fortement typé. Si vous faites n'importe quelle forme de mésappariement de type tomfoolery, le compilateur vous le dira.
La notation hongroise n'a de sens que dans les langues sans types définis par l'utilisateur . Dans un langage fonctionnel ou OO moderne, vous encoderiez des informations sur le "type" de valeur dans le type de données ou la classe plutôt que dans le nom de la variable.
Plusieurs réponses référence article de Joels . Notez cependant que son exemple est dans VBScript, qui ne supportait pas les classes définies par l'utilisateur (du moins pendant longtemps). Dans une langue avec des types définis par l'utilisateur, vous résoudriez le même problème en créant un type HtmlEncodedString, puis en laissant la méthode Write n'accepter que cela. Dans un langage typé statiquement, le compilateur interceptera toutes les erreurs d'encodage. Dans une typographie dynamique, vous obtiendrez une exception d'exécution - mais dans tous les cas, vous êtes protégé contre l'écriture de chaînes non encodées. Les notations hongroises transforment simplement le programmeur en un vérificateur de type humain, avec le type de travail généralement mieux géré par un logiciel.
Joel fait la distinction entre "systèmes hongrois" et "applications hongroise", où "systèmes hongrois" code les types intégrés tels que int, float, etc., et "applications hongrois" code "types", méta-informations de niveau supérieur. sur une variable au-delà du type de machine, vous pouvez créer des types définis par l'utilisateur dans un OO ou un langage fonctionnel moderne). Il n'y a donc pas de distinction entre type et "type" dans ce sens, les deux peuvent être représentés par le système de types - et "applications", l'hongrois est tout aussi redondant que "systèmes" en hongrois.
Donc, pour répondre à votre question: Systems hungarian ne serait utile que dans un langage non sécurisé et faiblement typé, par exemple. assigner une valeur float à une variable int va planter le système. La notation hongroise a été spécifiquement inventée dans les années soixante pour être utilisée dans BCPL , un langage assez basique qui ne fait aucune vérification de type. Je ne pense pas que les langages d'usage courant aujourd'hui aient ce problème, mais la notation a survécu comme une sorte de programmation culte du fret .
Apps hungarian sera logique si vous travaillez avec une langue sans types définis par l'utilisateur, comme VBScript ou les premières versions de VB. Peut-être aussi les premières versions de Perl et PHP. Encore une fois, l’utiliser dans une langue moderne est un véritable culte du fret.
Dans toute autre langue, le hongrois est simplement laid, redondant et fragile. Il répète des informations déjà connues du système de types, et vous ne devez pas vous répéter . Utilisez un nom descriptif pour la variable qui décrit l'intention de cette instance spécifique du type. Utilisez le système de types pour coder les invariants et les méta-informations sur les "types" ou "classes" de variables - c'est-à-dire. les types.
L'article général de Joels - avoir un mauvais code pour avoir l'air faux - est un très bon principe. Cependant, une meilleure protection contre les bogues consiste à - dans la mesure du possible - empêcher le code erroné d'être détecté automatiquement par le compilateur.
J'utilise toujours la notation hongroise pour tous mes projets. Je trouve cela très utile lorsque je traite avec des centaines d'identifiants différents.
Par exemple, lorsque j'appelle une fonction nécessitant une chaîne, je peux taper 's' et appuyer sur control-space et mon IDE) me montrera exactement les noms de variables précédés de 's'.
Un autre avantage, lorsque je préfixe u pour unsigned et i pour les ints signés, je vois immédiatement où je mélange des signes signé et non signé de manière potentiellement dangereuse.
Je ne me souviens pas du nombre de fois où, dans une énorme base de code de 75 000 lignes, des bogues ont été causés (par moi-même et d'autres également) en raison de la désignation de variables locales identiques aux variables de membre existantes de cette classe. Depuis lors, je préfixe toujours les membres avec 'm_'
C'est une question de goût et d'expérience. Ne frappez pas avant d'avoir essayé.
Vous oubliez la raison numéro un pour inclure cette information. Cela n'a rien à voir avec vous, le programmeur. Cela a tout à voir avec la personne qui arrive sur la route 2 ou 3 ans après votre départ de l'entreprise, qui doit lire ces informations.
Oui, un IDE identifiera rapidement les types pour vous. Toutefois, lorsque vous parcourez de longs lots de code "règles métier", il est agréable de ne pas avoir à faire une pause sur chaque variable pour trouver Lorsque je vois des choses comme strUserID, intProduct ou guiProductID, cela fait beaucoup plus de temps .
Je conviens que MS est allé trop loin avec certaines de ses conventions de dénomination - je classe cela dans la pile "trop d'une bonne chose".
Les conventions de dénomination sont de bonnes choses, à condition de s'y tenir. J'ai parcouru suffisamment de vieux codes qui m'ont obligé à consulter en permanence les définitions de tant de variables portant le même nom que I Push "camel casing" (comme on l'appelait dans un emploi précédent). À l’heure actuelle, j’ai un travail qui comporte plusieurs milliers de lignes de code classique avec code VBScript ASP) et qui n’a pas été commenté - et c’est un cauchemar qui consiste à essayer de résoudre le problème.
Tacking sur les caractères cryptiques au début de chaque nom de variable est inutile et montre que le nom de la variable en soi n'est pas assez descriptif. De toute façon, la plupart des langues exigent le type de variable lors de la déclaration, de sorte que les informations sont déjà disponibles.
Il existe également le cas où, au cours de la maintenance, un type de variable doit changer. Exemple: si une variable déclarée "uint_16 u16foo" doit devenir non signée 64 bits, l'une des deux choses suivantes se produira:
- Vous allez parcourir et modifier chaque nom de variable (en veillant à ne pas associer des variables non liées avec le même nom), ou
- Il suffit de changer le type et de ne pas changer le nom, ce qui ne fera que créer de la confusion.
Joel Spolsky a écrit un bon article sur ce blog. http://www.joelonsoftware.com/articles/Wrong.html En gros, il s'agit de ne pas rendre votre code plus difficile à lire lorsqu'un décent IDE vous le dira) Voulez-vous taper la variable si vous ne vous en souvenez plus? De plus, si votre code est suffisamment compartimenté, vous n'avez pas à vous rappeler quelle variable a été déclarée trois pages plus haut.
La portée n'est-elle pas plus importante que le type de nos jours, par exemple.
* l for local
* a for argument
* m for member
* g for global
* etc
Avec les techniques modernes de refactorisation de l'ancien code, rechercher et remplacer un symbole car son type est fastidieux, le compilateur intercepte les modifications de type, mais n'attrape souvent pas l'utilisation incorrecte de la portée, des conventions de dénomination judicieuses aident ici.
Il n'y a aucune raison pour laquelle vous ne devriez pas utiliser correctement la notation hongroise. Son impopularité est due à un long tir en arrière contre la mauvaise utilisation de la notation hongroise, en particulier dans les API Windows.
Au mauvais vieux temps, avant de ressembler à un IDE existait pour DOS (il y a de fortes chances que vous n'ayez pas assez de mémoire libre pour exécuter le compilateur sous Windows, votre développement a donc été fait sous DOS) , si vous avez survolé votre souris au-dessus d’un nom de variable (en supposant que vous en ayez une), avez-vous eu à gérer? Des fonctions de rappel d’événement dans lesquelles tout vous a été transmis sous forme de fichier 16 bits. int (Word) ou 32 bits int (LONG Word). Vous devez ensuite convertir ces paramètres en types appropriés pour le type d'événement donné. En réalité, une grande partie de l'API était pratiquement sans type.
Le résultat, une API avec des noms de paramètres comme ceux-ci:
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
Notez que les noms wParam et lParam, bien que plutôt terribles, ne sont pas pires que de les nommer param1 et param2.
Pour aggraver les choses, Window 3.0/3.1 avait deux types de pointeurs, proches et lointains. Ainsi, par exemple, la valeur de retour de la fonction de gestion de la mémoire LocalLock était un PVOID, mais la valeur de retour de GlobalLock était un LPVOID (avec le "L" pour long). Cette horrible notation a ensuite été étendue de telle sorte qu'une chaîne l ong p ointer était préfixée lp, pour la distinguer d'une chaîne qui avait été simplement malloc 'ré.
Ce n'est pas surprenant qu'il y ait eu un retour de bâton contre ce genre de chose.
La notation hongroise peut être utile dans les langues sans vérification de type à la compilation, car elle permettrait au développeur de se rappeler rapidement comment la variable particulière est utilisée. Il ne fait rien pour la performance ou le comportement. Il est supposé améliorer la lisibilité du code et est principalement une question de goût et de style de codage. Pour cette raison même, de nombreux développeurs le critiquent - tout le monde n’a pas le même câblage dans le cerveau.
Pour les langages de vérification de type à la compilation, il est généralement inutile - faire défiler quelques lignes doit révéler la déclaration et donc le type. Si vos variables globales ou votre bloc de code s'étend sur beaucoup plus d'un écran, vous rencontrez des problèmes de conception et de réutilisabilité de Grave. L'une des critiques est donc que la notation hongroise permet aux développeurs d'avoir une mauvaise conception et de s'en tirer facilement. C'est probablement l'une des raisons pour lesquelles nous sommes haï.
D'autre part, il peut y avoir des cas où même les langages de vérification de type au moment de la compilation tireraient profit de la notation hongroise - void pointeurs ou HANDLE dans l'API win32. Cela obscurcit le type de données réel, et il pourrait être intéressant d’utiliser la notation hongroise à cet endroit. Cependant, si l’on peut connaître le type de données au moment de la construction, pourquoi ne pas utiliser le type de données approprié.
En général, il n’existe aucune raison difficile de ne pas utiliser la notation hongroise. C'est une question de goûts, de politiques et de style de codage.
En tant que programmeur Python, la notation hongroise se défait assez vite. En Python, je me moque de savoir si quelque chose est une chaîne - ça me dérange si cela peut agissez comme une chaîne (c'est-à-dire si elle a une méthode ___str___() qui retourne une chaîne).
Par exemple, supposons que foo soit un entier, 12
foo = 12
La notation hongroise nous dit que nous devrions appeler iFoo ou quelque chose comme ça, pour indiquer qu'il s'agit d'un entier, pour que nous sachions plus tard ce que c'est. Sauf en Python, cela ne fonctionne pas, ou plutôt, cela n'a pas de sens. En Python, je décide quel type je veux quand je l'utilise. Est-ce que je veux une ficelle? bien si je fais quelque chose comme ça:
print "The current value of foo is %s" % foo
Notez la chaîne %s. Foo n'est pas une chaîne, mais l'opérateur % Appellera foo.___str___() et utilisera le résultat (en supposant qu'il existe). foo est toujours un entier, mais nous le traitons comme une chaîne si nous voulons une chaîne. Si nous voulons un float, alors nous le traitons comme un float. Dans les langages à typage dynamique tels que Python, la notation en hongrois est inutile, car le type utilisé n’a pas d’importance tant que vous ne l’utilisez pas. Si vous avez besoin d’un type spécifique, veillez simplement à le transtyper (par exemple, float(foo)) quand vous l'utilisez.
Notez que les langages dynamiques comme PHP ne présentent pas cet avantage - PHP essaie de faire "ce qu'il faut" en arrière-plan en se basant sur un ensemble obscur de règles). que presque personne ne l’a mémorisée, ce qui entraîne souvent des dégâts catastrophiques inattendus. Dans ce cas, un mécanisme de nommage, comme $files_count ou $file_name, peut être pratique.
À mon avis, la notation hongroise est comme une sangsue. Dans le passé, ils étaient peut-être utiles, ou du moins semblaient-ils utiles, mais de nos jours, il suffit de beaucoup de dactylographie pour ne pas en retirer beaucoup.
Le IDE devrait donner cette information utile. Le hongrois aurait peut-être fait une sorte de sens (pas beaucoup, mais un certain genre) de sens quand les IDE étaient beaucoup moins avancés.
Apps Hungarian est grec pour moi - dans le bon sens
En tant qu’ingénieur et non programmeur, j’ai immédiatement lu l’article de Joel sur les avantages d’App Apps Hungarian: "Donner un mauvais code à un faux" . J'aime Apps Hungarian, car il imite la manière dont l'ingénierie, la science et les mathématiques représentent des équations et des formules à l'aide de symboles sur- et super-scriptés (comme les lettres grecques, les symboles mathématiques, etc.). opérateurs, etc.). Prenons un exemple particulier de loi de Newton sur la gravité universelle : d'abord en notation mathématique standard, puis dans le pseudo-code hongrois de Google Apps:
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
Dans la notation mathématique, les symboles les plus importants sont ceux représentant le type kind des informations stockées dans la variable: force, masse, vecteur de position, etc. Les indices jouent un second fiddle pour préciser: la position de quoi ? C’est exactement ce que fait Apps Hungarian; c'est vous dire le genre de la chose stockée dans la variable d'abord, puis entrer dans les détails - à propos du code le plus proche peut accéder à la notation mathématique.
Il est clair que le typage fort peut résoudre les exemples de chaînes sûres/non sécurisées de l'essai de Joel, mais vous ne définiriez pas de types séparés pour les vecteurs position et vélocité; les deux sont des tableaux doubles de taille trois et tout ce que vous êtes susceptible de faire à l'un pourrait s'appliquer à l'autre. En outre, il est parfaitement logique de concaténer la position et la vitesse (pour créer un vecteur d’état) ou de prendre leur produit scalaire, mais probablement de ne pas les ajouter. Comment la dactylographie autoriserait-elle les deux premières et interdirait-elle la seconde, et comment un tel système s'étendrait-il à toutes les opérations possibles que vous voudriez protéger? À moins que vous ne souhaitiez encoder toutes les mathématiques et la physique dans votre système de dactylographie.
En plus de tout cela, beaucoup d'ingénierie est faite dans des langages de haut niveau faiblement typés comme Matlab, ou d'anciens langages comme Fortran 77 ou Ada.
Donc, si vous avez un langage sophistiqué et IDE et Apps Hungarian ne vous aide pas, alors oubliez-le - beaucoup de gens l'ont apparemment. Mais pour moi, pire qu'un programmeur novice qui travaille Dans les langues faiblement ou dynamiquement typées, je peux écrire un meilleur code plus rapidement avec Apps Hungarian que sans.
Démystifier les avantages de la notation hongroise
- Cela permet de distinguer les variables.
Si le type est tout ce qui distingue une valeur d'une autre, il ne peut s'agir que de la conversion d'un type en un autre. Si vous avez la même valeur convertie entre les types, il est probable que vous devriez le faire dans une fonction dédiée à la conversion. (J'ai vu des restes de VB6 en hongrois utiliser des chaînes dans tous leurs paramètres de méthode simplement parce qu'ils ne pouvaient pas comprendre comment désérialiser un objet JSON ni comprendre correctement comment déclarer ou utiliser des types pouvant être annulés. ) Si vous avez deux variables distinguées uniquement par le préfixe hongrois et qu'elles ne sont pas une conversion de l'une à l'autre, vous devez préciser votre intention à l'aide de ces variables.
- Cela rend le code plus lisible.
J'ai trouvé que la notation hongroise rend les gens paresseux avec leurs noms de variables. Ils ont quelque chose pour le distinguer, et ils ne ressentent pas le besoin de préciser son but. C’est ce que vous trouverez généralement dans le code avec notation notée en hongrois versus moderne: sSQL vs groupSelectSql ( ou généralement pas de sSQL du tout car ils sont supposés utiliser l’ORM introduit auparavant par développeurs. ), sValue vs formCollectionValue ( ou généralement pas de sValue non plus, car ils se trouvent dans MVC et devraient utiliser ses fonctions de liaison de modèle ), sType vs publishSource, etc.
Ce ne peut pas être la lisibilité. Je vois plus de sTemp1, sTemp2 ... sTempN parmi les restes de VB6 hongrois que tous les autres.
- Cela évite les erreurs.
Ce serait en vertu du numéro 2, qui est faux.
L'article de Joel est excellent, mais il semble omettre un point important:
Le hongrois rend une "idée" particulière (type + nom d'identifiant) unique, ou quasi unique, à travers la base de code - même une très grande base de code.
C'est énorme pour la maintenance du code. Cela signifie que vous pouvez utiliser la bonne recherche de texte sur une seule ligne (grep, findstr, "trouver dans tous les fichiers") pour retrouver CHAQUE mention de cette "idée".
Pourquoi est-ce important quand nous avons des IDE qui savent lire le code? Parce qu'ils ne sont pas encore très doués pour ça. Cela est difficile à voir dans une petite base de code, mais évident dans une grande - quand l'idée peut être mentionnée dans les commentaires, les fichiers XML, les scripts Perl, ainsi que dans des endroits en dehors du contrôle de source (documents, wikis, bases de données de bogues).
Vous devez être un peu prudent, même ici - par exemple Le collage de jetons dans les macros C/C++ peut masquer les mentions de l'identifiant. Ces cas peuvent être traités à l'aide de conventions de codage et, de toute façon, ils ont tendance à n'affecter qu'une minorité des identifiants de la base de code.
P.S. Au point d'utiliser le système de types par rapport au hongrois - il est préférable d'utiliser les deux. Vous n'avez besoin que d'un code erroné pour avoir l'air mauvais si le compilateur ne l'attrape pas pour vous. Il existe de nombreux cas où il est impossible de faire en sorte que le compilateur le récupère. Mais là où c'est faisable - oui, faites-le plutôt!
Cependant, lors de l'examen de la faisabilité, prenez en compte les effets négatifs de la séparation des types. par exemple. en C #, encapsuler 'int' avec un type non intégré a d'énormes conséquences. Cela a donc du sens dans certaines situations, mais pas dans toutes.
J'ai toujours pensé qu'un préfixe ou deux au bon endroit ne ferait pas de mal. Je pense que si je peux transmettre quelque chose d’utile, comme "Hé, c’est une interface, ne comptez pas sur un comportement spécifique", comme dans IEnumerable, je devrais le faire. Les commentaires peuvent encombrer les choses bien plus qu’un symbole à un ou deux caractères.
C'est incroyablement redondant et inutile dans la plupart des IDE modernes, où ils font un bon travail pour rendre le type apparent.
De plus, pour moi, c'est ennuyant de voir intI, strUserName, etc. :)
Si je pense que des informations utiles sont communiquées, pourquoi ne devrais-je pas les mettre là où elles sont disponibles?
Alors, qui se soucie de ce que les autres pensent? Si vous le trouvez utile, utilisez la notation.
Mon expérience est mauvaise parce que:
1 - alors vous cassez tout le code si vous devez changer le type d’une variable (c’est-à-dire si vous devez étendre un entier de 32 bits à un entier de 64 bits);
2 - Ces informations sont inutiles, car le type est déjà dans la déclaration ou vous utilisez un langage dynamique dans lequel le type actuel ne devrait pas être aussi important en premier lieu.
De plus, avec un langage acceptant la programmation générique (c'est-à-dire des fonctions pour lesquelles le type de certaines variables n'est pas déterminé lorsque vous écrivez la fonction) ou avec un système de frappe dynamique (c'est-à-dire lorsque le type n'est même pas déterminé au moment de la compilation), comment nommeriez-vous votre des variables? Et la plupart des langues modernes supportent l’une ou l’autre, même si elles sont restreintes.
C'est une convention utile pour nommer des contrôles sur un formulaire (btnOK, txtLastName, etc.), si la liste des contrôles apparaît dans une liste déroulante alphabétisée dans votre IDE.
Dans Joel Spolsky, Making Wrong Code Look Wrong , il explique que ce que tout le monde pense de notation hongroise (qu'il appelle systèmes hongrois) n'est pas ce qu'il était vraiment destiné à être (ce qu'il appelle Apps Hungarian). Faites défiler jusqu’à la rubrique . Je suis Hongrie pour consulter cette discussion.
Fondamentalement, Systems Hungarian ne vaut rien. Il vous dit simplement la même chose que votre compilateur et/ou IDE vous dira).
Apps Hungarian vous explique ce que la variable est censée signifier et peut en réalité être utile.
J'ai tendance à utiliser la notation hongroise avec les contrôles serveur ASP.NET niquement, sinon je trouve qu'il est trop difficile de déterminer quels contrôles sont ceux du formulaire.
Prenez cet extrait de code:
<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />
Si quelqu'un peut montrer un meilleur moyen de disposer de cet ensemble de noms de contrôle sans hongrois, je serais tenté de passer à celui-ci.
Dans les mots du maître:
http://www.joelonsoftware.com/articles/Wrong.html
Une lecture intéressante, comme d'habitude.
Extraits:
"Quelqu'un, quelque part, a lu le journal de Simonyi, dans lequel il utilisait le mot" type "et pensait qu'il voulait dire type, comme classe, comme dans un système de types, comme la vérification de type effectuée par le compilateur. Ce n'est pas le cas. Il expliqua très attentivement. exactement ce qu'il entendait par le mot "type", mais cela n'a pas aidé. Le mal était fait. "
"Mais Apps Hungarian a toujours une valeur énorme, en ce sens qu’il augmente la colocalisation dans le code, ce qui facilite la lecture, l’écriture, le débogage et la maintenance du code et, surtout, donne l’air faux.
Assurez-vous de disposer de suffisamment de temps avant de lire Joel On Software. :)
Plusieurs raisons:
- Tout moderne IDE vous donnera le type de variable en survolant simplement la variable avec la souris.
- La plupart des noms de types sont très longs (pensez HttpClientRequestProvider ) pour être raisonnablement utilisés comme préfixe.
- Les informations de type ne portent pas les informations right , il s'agit simplement de paraphraser la déclaration de variable, au lieu de souligner le purpose du variable (pensez myInteger vs pageSize ).
Je ne pense pas que tout le monde est enragé contre elle. Dans les langues sans types statiques, c'est très utile. Je le préfère vraiment quand il est utilisé pour donner des informations qui ne sont pas déjà dans le type. Comme en C, char * szName indique que la variable fera référence à une chaîne terminée par null - ce qui n'est pas implicite dans char * - bien sûr, un typedef serait également utile.
Joel avait un excellent article sur l'utilisation de l'hongrois pour savoir si une variable était encodée en HTML ou non:
http://www.joelonsoftware.com/articles/Wrong.html
En tout cas, j'ai tendance à ne pas aimer le hongrois quand il est utilisé pour transmettre des informations que je connais déjà.
Bien sûr, lorsque 99% des programmeurs sont d’accord sur quelque chose, il ya un problème. La raison pour laquelle ils sont d’accord ici est que la plupart d’entre eux n’ont jamais utilisé correctement la notation hongroise.
Pour un argumentaire détaillé, je vous renvoie à un article de blog que j'ai rédigé sur le sujet.
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
J'ai commencé à coder à peu près au moment où la notation hongroise a été inventée et la première fois que j'ai été forcé de l'utiliser pour un projet, je l'ai détesté.
Après un moment, je me suis rendu compte que quand tout était fait correctement, cela aidait vraiment et ces jours-ci, j'adore.
Mais comme pour tout ce qui est bien, il faut apprendre et comprendre et le faire correctement prend du temps.
Je pense que la chose entière de l'aspect esthétique est sur-excité. Si c'était la chose la plus importante, nous ne nous appellerions pas développeurs, mais graphique concepteurs.
Une partie importante, je pense, est que vous décrivez quel est le rôle de votre objet, pas ce qu’il est. Vous ne vous appelez pas HumanDustman, car dans un autre contexte, vous ne voudriez surtout pas être un humain.
Pour les besoins de la refactorisation, il est également très important:
public string stringUniqueKey = "ABC-12345";
Et si vous décidiez d'utiliser un GUID au lieu d'une chaîne, votre nom de variable aurait l'air stupide après le refactoring de tout le code faisant référence.
Ou:
public int intAge = 20;
En changeant cela en float, vous auriez le même problème. Etc.
La notation hongroise a été utilisée de manière abusive, en particulier par Microsoft, ce qui a conduit à des préfixes plus longs que le nom de la variable, ce qui la rend assez rigide, notamment lorsque vous modifiez les types (le fameux lparam/wparam, de type/taille différent dans Win16, identique dans Win32 ).
Ainsi, à la fois en raison de cet abus et de son utilisation par M $, il a été jugé inutile.
Dans mon travail, nous codons en Java, mais le fondateur appartient au monde MFC, utilisez donc un style de code similaire (accolades alignées, j'aime ceci!, Majuscules aux noms de méthodes, je suis habitué à cela, préfixe comme m_ aux membres de la classe (champs ), s_ aux membres statiques, etc.).
Et ils ont dit que toutes les variables devraient avoir un préfixe indiquant son type (par exemple, un BufferedReader est nommé brData). Ce qui est indiqué comme étant une mauvaise idée, car les types peuvent changer mais les noms ne suivent pas, ou les codeurs ne sont pas cohérents dans l'utilisation de ces préfixes (je vois même aBuffer, theProxy, etc.!).
Personnellement, j'ai choisi quelques préfixes que je trouve utiles, le plus important étant b de préfixer les variables booléennes, car ce sont les seules où j'autorise une syntaxe comme if (bVar) (pas d'utilisation de la diffusion automatique de certaines valeurs). vrai ou faux). Quand j'ai codé en C, j'ai utilisé un préfixe pour les variables allouées avec malloc. Pour rappel, il devrait être libéré plus tard. Etc.
Donc, fondamentalement, je ne rejette pas cette notation dans son ensemble, mais j'ai pris ce qui me semblait approprié.
Et bien sûr, lorsque je contribue à un projet (travail, open source), j’utilise simplement les conventions en vigueur!
Pendant des années, j'ai utilisé la notation hongroise dans ma programmation. Hormis un certain fouillis visuel et la tâche de changer le préfixe quand j'ai changé le type de données, personne ne pourrait me convaincre du contraire. Jusqu'à récemment, je devais combiner les assemblys existants C # et VB.NET dans la même solution.
Le résultat: je devais passer un "fltSomeVariable" à un paramètre de méthode "sngSomeVariable". Même en tant que programmeur en C # et en VB.NET, cela m'a pris au dépourvu et m'a fait faire une pause un instant. (C # et VB.NET utilisent parfois des noms différents pour représenter le même type de données - float et single, par exemple.)
Considérons maintenant ceci: que se passe-t-il si vous créez un composant COM pouvant être appelé à partir de plusieurs langues? La "conversion" VB.NET et C # était facile pour un programmeur .NET. Mais qu'en est-il de quelqu'un qui développe en C++ ou en Java? "DwSomeVariable" signifie-t-il quelque chose pour un développeur .NET qui n'est pas familier avec C++?
Si vous ne connaissez pas le type d'une variable sans qu'on vous le dise, vous ne devriez probablement pas le jouer de toute façon.
Le type pourrait également ne pas être si important. Si vous savez ce que font les méthodes, vous pouvez comprendre ce qui est fait avec la variable et ensuite vous allez voir ce que le programme fait.
Il peut y avoir des moments où vous le voulez; lorsque le type est important et que la déclaration n'est pas proche ou que le type ne peut pas être déduit facilement. Mais cela ne devrait jamais être considéré comme absolu
- Ils sont une horreur des yeux
- Votre IDE devrait pouvoir vous dire tout ce que vous devez savoir sur le type d'une variable
- Les bons noms (ce que HN fait obstacle) devraient vous communiquer tout ce que vous devez savoir sur une variable.
Le hongrois est mauvais parce qu’il enlève des caractères précieux aux noms de variables en échange de quoi, des informations de type?
Tout d’abord, dans un langage fortement typé, le compilateur vous avertira si vous faites vraiment des bêtises.
Deuxièmement, si vous croyez en un bon code modulaire et que vous n’effectuez pas trop de travail dans une fonction, vos variables sont probablement déclarées juste au-dessus du code dans lequel elles sont utilisées (vous avez donc le type à cet endroit).
Troisièmement, si vous préfixez chaque pointeur avec p et chaque classe avec C, vous bousillez vraiment la capacité de votre IDE moderne Nice à faire intellisense Vous pouvez appuyer sur Entrée et le compléter pour vous - si vous préfixez chaque classe par C, vous avez toujours au moins une lettre supplémentaire à taper) ...
Je ne trouve pas de lien, mais je me souviens avoir lu quelque part (avec lequel je suis d'accord) qu'éviter la notation en hongrois se traduirait par un meilleur style de programmation.
Lorsque vous programmez une instruction de votre programme, vous ne devriez pas penser à "quel type est cet objet" avant d'appeler sa méthode, mais plutôt à penser à "qu'est-ce que je veux en faire", "quel message lui envoyer ".
Genre de concept vague à expliquer, mais je pense que ça marche.
Par exemple, si vous avez un nom de client stocké dans la variable customerName, vous ne devez pas vous soucier de savoir s'il s'agit d'une chaîne ou d'une autre classe. Plus important de penser à ce que vous voulez de cet objet. Voulez-vous qu'il imprime (), getFirstName (), getLastName (), convertToString (), etc. Une fois que vous en faites une instance de la classe String et que vous la considérez comme acquise, vous vous limitez vous-même et votre conception, car vous devez tout construire autre logique dont vous avez besoin ailleurs dans le code.