Pourquoi ne devrais-je pas utiliser la & # 8220; notation hongroise & # 8221 ;?

https://stackoverflow.com/questions/111933

02-07-2019
|

Question

Je sais ce que signifie le hongrois - 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: Les gens utilisent-ils le Les conventions de nommage hongroises dans le monde réel?

La solution

La plupart des gens utilisent la notation hongroise de manière erronée et obtiennent des résultats erronés.

Lisez cet excellent article de Joel Spolsky: Rendre le code erroné et le rendu incorrect .

En bref, la notation hongroise dans laquelle vous préfixez les noms de vos variables avec leur type (chaîne) (Systems Hungarian) est incorrecte car elle est inutile.

Notation hongroise telle que voulue par son auteur où vous préfixez le nom de la variable avec son type (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 précieux.

Autres conseils

vUsing adjHungarian nnotation vmakes nreading ncode adjdifficult.

Joel a tort, et voici pourquoi.

Cette " application " les informations dont il parle devraient être encodées 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 qu'il soit 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 non sécurisé à sûr, vous devrez peut-être traiter avec une sorte de fonction de désinfection.

Beaucoup de choses dont Joel parle en tant que "types" ne sont pas des genres; ce sont en fait des types.

Ce qui manque à la plupart des langues, cependant, est un système de types suffisamment expressif pour imposer ce type de distinctions. Par exemple, si C avait une sorte de "type fort" (où le nom 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 n'a pas pu être converti en std :: string (et ainsi de suite). pourrait participer à la résolution de surcharge etc. etc.) alors nous n'aurions pas besoin de préfixes idiots.

Donc, 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". Cela devrait être "faire en sorte que le mauvais code ait l'air mauvais pour le compilateur ".

Je pense que cela encombre le code source.

Cela ne vous rapporte pas grand chose non plus dans un langage fortement typé. Si vous faites une erreur de type mismatch tomfoolery, le compilateur vous en informera.

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 font référence à l’article sur 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 un type typé dynamiquement, 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 distingue les "systèmes hongrois". et "applications hongroise", où "systèmes hongrois". encode les types intégrés tels que int, float, etc., et "apps hungarian". encode les "types", qui sont des méta-informations de niveau supérieur sur la variable au-delà du type de machine. Dans un langage OO ou fonctionnel, vous pouvez créer des types définis par l'utilisateur. Il n'y a donc pas de distinction entre le type et le type. en ce sens - les deux peuvent être représentés par le système de types - et "applications". le hongrois est aussi redondant que les "systèmes" 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écialement inventée dans les années soixante pour être utilisée dans le BCPL , un langage assez bas Ne faites pas de vérification du type. Je ne pense pas que les langues couramment utilisées aujourd'hui aient ce problème, mais la notation a été conservée comme une sorte de programmation culte du cargo .

Les applications hongroise auront du sens si vous travaillez avec une langue sans types définis par l'utilisateur, comme VBScript hérité 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 les informations déjà connues du système de typage 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 des invariants et des méta-informations sur les "types". ou " classes " de variables - à savoir. types.

L’article principal de l’article de Joels, qui veut que le code soit faux, est un très bon principe. Cependant, une meilleure protection contre les bogues consiste à - dans la mesure du possible - éviter que le code erroné soit 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'.

Autre avantage, lorsque je préfixe u pour unsigned et i pour les signatures, je vois immédiatement où je mélange des signatures et des signatures 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) en raison de la désignation des variables locales de la même manière que les 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 principale raison d'inclure cette information. Cela n'a rien à voir avec vous, le programmeur. Cela a tout à voir avec la personne qui entre dans la rue deux ou trois ans après votre départ de la société 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 savoir de quel type il s'agit. Lorsque je vois des choses comme strUserID, intProduct ou guiProductID, cela simplifie beaucoup le temps de montée en puissance.

Je conviens que les États membres sont allés beaucoup trop loin avec certaines conventions de dénomination - je classe cela dans la catégorie "trop ??d'une bonne chose". pile.

Les conventions de dénomination sont bonnes, à condition de les respecter. 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 j'ai poussé "chameau". (comme on l'appelait à un emploi précédent). À l’heure actuelle, j’ai un travail qui comporte plusieurs milliers de lignes de code ASP classique sans commentaires avec VBScript et c’est un cauchemar qui consiste à essayer de comprendre.

Tacking sur les caractères cryptiques au début de chaque nom de variable est inutile et montre que le nom de la variable par lui-même n'est pas assez descriptif. De toute façon, la plupart des langues nécessitent le type de variable lors de la déclaration, de sorte que les informations sont déjà disponibles.

Il existe également le cas où, lors de la maintenance, un type de variable doit changer. Exemple: si une variable déclarée comme "uint_16 u16foo" doit devenir non signé 64 bits, l'une des deux choses suivantes se produira:

Vous allez modifier et changer chaque nom de variable (en veillant à ne pas créer de variables sans rapport avec le même nom), ou
Changez simplement le type et non le nom, ce qui ne ferait que créer de la confusion.

Joel Spolsky a écrit un bon blog à ce sujet. http://www.joelonsoftware.com/articles/Wrong.html En gros, il s'agit de ne pas rendre votre code plus difficile à lire lorsqu'un IDE décent vous dira que vous voulez 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 de plus.

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, les conventions de nommage judicieuses aident ici.

Il n'y a aucune raison pour que vous n'utilisiez pas correctement la notation hongroise. Son impopularité est due à une longue réprimande contre la mauvaise utilisation de la notation hongroise, en particulier dans les API Windows.

À l'époque maléfique, avant que tout ce qui ressemble à un IDE n'existait pour DOS (il est probable que vous ne disposiez pas de suffisamment de mémoire libre pour exécuter le compilateur sous Windows, votre développement a donc été effectué sous DOS). toute aide de survoler votre souris avec un nom de variable. (En supposant que vous ayez une souris.) Vous avez eu à gérer des fonctions de rappel d’événement dans lesquelles tout vous était transmis en tant qu’int 16 bits (WORD) ou 32 bits (LONG WORD). Vous deviez ensuite convertir ces paramètres en types appropriés pour le type d'événement donné. En fait, une grande partie de l’API était pratiquement sans caractères.

Le résultat, une API avec des noms de paramètres tels que ceux-ci:

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

Notez que les noms wParam et lParam, bien qu'assez 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, proche et lointain. Ainsi, par exemple, la valeur renvoyée par la fonction de gestion de la mémoire LocalLock était un PVOID, mais la valeur renvoyée par GlobalLock était un LPVOID (avec le «L» pour longtemps). Cette horrible notation a ensuite été étendue de sorte qu'une chaîne l ong ?? p soit précédée de lp , afin de la distinguer d'une chaîne qui avait été simplement malloc 'd.

Il 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 au moment de la compilation, il est généralement inutile - faire défiler quelques lignes jusqu'à 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é graves. 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 haineux.

D'un autre côté, il peut arriver que même les langages de vérification de type au moment de la compilation tirent parti des indicateurs de notation en hongrois - void ou des HANDLE dans win32 API. 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 règles et de style de codage.

En tant que programmeur Python, la notation hongroise se défait assez vite. En Python, je ne me soucie pas de savoir si quelque chose est une chaîne - cela me importe si cela peut agir comme une chaîne (c'est-à-dire si elle a un ___ 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 que c'est 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? Eh 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) ) lorsque vous l'utilisez.

Notez que les langages dynamiques tels que PHP ne présentent pas cet avantage. PHP essaie de faire "ce qu'il convient" en arrière-plan, en se basant sur un ensemble de règles obscur que presque personne n'a mémorisé, ce qui entraîne souvent des dégâts catastrophiques inattendus. Dans ce cas, une sorte de mécanisme de nommage, comme $ nombre_fichiers ou $ nom_fichier , 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.

L’EDI devrait communiquer ces informations utiles. Le hongrois aurait peut-être fait sens (pas beaucoup, mais plutôt) quand les IDE étaient beaucoup moins avancés.

Le hongrois est un mot grec pour moi - dans le bon sens

En tant qu’ingénieur et non programmeur, j’ai tout de suite lu l’article de Joel sur les mérites d’App Apps Hungarian: " Faire en sorte que le code soit 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 sous-écrit et surexprimés (comme les lettres grecques, les opérateurs mathématiques, etc.). Prenons un exemple particulier de La loi de Newton sur la gravité universelle : première en notation mathématique standard, et puis dans le pseudo-code hongrois de Google Apps:

La loi de la gravité universelle de Newton pour la Terre et Mars

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

Dans la notation mathématique, les symboles les plus importants sont ceux qui représentent le type d’informations stockées dans la variable: force, masse, vecteur de position, etc. Les indices sont utilisés en second lieu pour clarifier: position quelle? C’est exactement ce que fait Apps Hungarian; cela vous dit d'abord le type de la chose stockée dans la variable, puis que vous entrez dans les détails - le code le plus proche peut atteindre la notation mathématique.

Il est clair que le typage fort peut résoudre l'exemple de chaîne sans danger / non sécurisé 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 réalisée dans des langages de haut niveau faiblement typés comme Matlab, ou des langages anciens comme Fortran 77 ou Ada.

Donc, si vous avez une langue de fantaisie et que IDE et Apps Hungarian ne vous aident pas, alors oubliez-les, beaucoup de gens en ont apparemment. Mais pour moi, pire qu'un programmeur novice qui travaille dans des langages typés faiblement ou dynamiquement, je peux écrire un meilleur code plus rapidement avec Apps Hungarian que sans.

C’est incroyablement redondant et inutile dans la plupart des IDE modernes, où ils rendent bien le type apparent.

De plus, pour moi, c'est ennuyant de voir intI, strUserName, etc.:)

Si je sens 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 jugez utile, utilisez la notation.

Mon expérience est mauvaise, car:

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 typage dynamique (c'est-à-dire lorsque le type n'est pas encore déterminé au moment de la compilation), comment vous nommez vos variables? Et la plupart des langues modernes supportent l’une ou l’autre, même sous une forme restreinte.

Dans Rendre le code erroné à Joel Spolsky , explique ce à quoi tout le monde pense. en tant que notation hongroise (qu’il appelle «systèmes Hungarian») n’est pas ce qu’elle était vraiment destinée à être (ce qu’il appelle «Apps Hungarian»). Faites défiler la liste Je suis la Hongrie pour consulter cette discussion.

En gros, Systems Hungarian ne vaut rien. Cela vous indique simplement la même chose que votre compilateur et / ou IDE vous dira.

Apps Hungarian vous indique le sens de la variable et peut même vous être utile.

J'ai toujours pensé qu'un préfixe ou deux au bon endroit ne ferait pas de mal. Je pense que si je peux communiquer quelque chose d’utile, comme "Hé, c’est une interface, ne comptez pas sur un comportement spécifique". juste là, 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 une convention utile pour nommer les contrôles d’un formulaire (btnOK, txtLastName, etc.), si la liste des contrôles s’affiche dans une liste déroulante alphabétisée de votre IDE.

J'ai tendance à utiliser la notation hongroise avec les contrôles serveur ASP.NET uniquement , sinon je trouve 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ôles sans hongrois, je serais tenté de passer à celui-ci.

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 presque 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 le bon vieux 'recherche de texte d'une seule ligne (grep, findstr, "trouver dans tous les fichiers") pour trouver CHAQUE mention de cette "idée".

Pourquoi est-ce important lorsque nous avons des IDE sachant lire le code? Parce qu'ils ne sont pas encore très doués pour ça. C'est difficile à voir dans une petite base de code, mais évident dans un grand - quand l'idée peut être mentionnée dans les commentaires, Les fichiers XML, les scripts Perl, ainsi que dans des endroits extérieurs au contrôle de source (documents, wikis, bases de données de bogues).

Vous devez être un peu prudent, même ici - par exemple. collage de jetons dans les macros C / C ++ peut masquer des mentions de l'identifiant. Ces cas peuvent être traités en utilisant 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!

Lorsque vous étudiez 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.

Cesser les avantages de la notation hongroise

Il 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 hongrois utiliser des chaînes dans tous leurs paramètres de méthode simplement parce qu'ils ne savaient pas comment désérialiser un objet JSON ni comprendre correctement comment déclarer ou utiliser des types Nullable. ) 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 avec elles.

Cela rend le code plus lisible.

J'ai constaté 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 parce qu’ils sont supposés utiliser l’ORM introduit par les développeurs précédents. ), sValue vs formCollectionValue ( ou généralement pas de sValue non plus, car ils se trouvent dans MVC et devraient utiliser ses fonctionnalités de liaison de modèle ), sType vs publishSource, etc.

Cela ne peut pas être la lisibilité. Je vois plus de sTemp1, sTemp2 ... sTempN parmi les restes de VB6 hongrois, que tous les autres joueurs réunis.

Cela évite les erreurs.

Ce serait en vertu du numéro 2, qui est faux.

Dans les mots du maître:

http://www.joelonsoftware.com/articles/Wrong.html

Une lecture intéressante, comme d'habitude.

Extraits:

"Quelque part, quelque part, a lu le document de Simonyi, dans lequel il utilisait le mot" type "et pensait parler de type, comme classe, comme dans un système de types, comme la vérification de type effectuée par le compilateur. Il n'a pas. Il a très soigneusement expliqué 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 considérable, 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, plus important encore, l'aspect du code erroné mal. "

Assurez-vous d’avoir le temps de lire Joel On Software. :)

Plusieurs raisons:

Tout IDE moderne vous donnera le type de variable en survolant simplement la souris avec la souris.
La plupart des noms de types sont très longs (pensez HttpClientRequestProvider ) à ê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 définir le but de la variable (think 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 un caractère null - ce qui n'est pas implicite dans char * - bien sûr, un typedef serait également utile.

Joel a publié un excellent article sur l'utilisation de l'hongrois pour savoir si une variable était codée au format HTML ou non:

http://www.joelonsoftware.com/articles/Wrong.html

Quoi qu’il en soit, j’ai tendance à ne pas aimer le hongrois quand il sert à communiquer 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 à l'époque où la notation hongroise avait é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 cela était fait correctement, cela aidait réellement et ces jours-ci, je l’aime.

Mais comme pour tout ce qui est bien, il faut apprendre et comprendre et le faire correctement prend du temps.

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 et a montré qu’elle est 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 cames du monde MFC, utilisez donc un style de code similaire (accolades alignées, j'aime ça!, majuscules aux noms de méthodes, je suis habitué à cela, préfixe comme m_ à la classe membres (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 pour préfixer les variables booléennes, car ce sont les seules où j’autorise une syntaxe telle que if (bVar) (no utilisation de la diffusion automatique de certaines valeurs à true ou false). 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, en gros, je ne rejette pas cette notation dans son ensemble, mais j'ai pris ce qui me semblait convenir à mes besoins.
Et bien sûr, lorsque je contribue à un projet (travail, open source), j'utilise simplement les conventions en vigueur!

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow