La notation hongroise des systèmes est-elle toujours une pratique utile? [fermé]

J'ai cherché sur le forum, mais je n'ai pas trouvé les réponses pour lesquelles il devrait être évité, seulement pourquoi ce n'est pas une solution miracle. Je ne pense donc pas que cette question soit en double.

Y at - il une VALIDE raison pour laquelle je désapprendre Systems hongrois je suis habitué?

Jusqu'à présent, je vois les avantages suivants à l'utiliser:

• Dénomination cohérente des variables
• Vous voyez le type sans rechercher (intellisense est mort / indexé la moitié du temps, donc c'est toujours une raison valable)
• La sémantique peut toujours être intégrée dans la deuxième partie du nom

Et les inconvénients suivants:

• Ça agace certaines personnes (aucune idée pourquoi)
• Si le type est modifié, le type peut ne pas correspondre à la dénomination de la variable (je ne pense pas que ce soit une raison valable, les types sont rarement modifiés et vous avez "renommer tout")

Alors pourquoi:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

est pire que:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

Je l'utilisais (il y a de nombreuses années) et je ne l'utilise plus. La raison principale est qu'il est superflu dans les langages OO avec un typage fort (C ++, Java) que j'ai utilisé pendant la majeure partie de ma carrière. Dans ces langages, si je définis bien mes types, le compilateur peut et appliquera la sécurité des types pour moi. Ainsi, tous les préfixes de dénomination ne sont qu'un encombrement qui rend les noms plus longs, donc plus difficiles à lire et à rechercher.

Dans tout programme OO bien écrit, la plupart de vos variables sont (des références à) des types définis par l'utilisateur. Si vous préfixez ceux-ci avec la même balise générale (comme opour "objet"), vous n'en tirerez aucun avantage, seulement les inconvénients. Si toutefois vous les préfixez avec des balises spécifiques à un type, vous vous retrouvez dans un labyrinthe d'essayer de trouver différentes abréviations pour un millier de types différents avec des noms souvent similaires *, et de ne pas oublier de les changer toutes lorsqu'un type ou son nom change (ce qui est pas rare du tout dans un programme bien entretenu).

Bien sûr, cela ne s'applique pas aux langues non OO, et peut ne pas s'appliquer aux langues faiblement et / ou dynamiquement typées (je n'ai aucune expérience avec celles-ci, à part C). Ni aux éditeurs / IDE sous-optimaux sans IntelliSense utilisable (ou son équivalent local). Et ce n'est que mes 2 cents. Donc, si la notation hongroise fonctionne pour votre équipe et votre projet, allez-y. L'important est de s'entendre sur cela (ainsi que sur un style de codage cohérent en général) avant le démarrage du projet, et de le maintenir cohérent à tout moment.

* _{Juste une courte liste de notre projet en cours: nous avons Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairet ChargeType, entre autres. De plus, nous avons également Contracts, Countries, Checkouts, Checkins ... et ce n'est que la lettre C, dans un projet qui ne serait probablement même pas qualifié de "taille raisonnable" par l'OP.}

Avis de non-responsabilité: je suis en fait un Hongrois, donc je pense pouvoir parler de cette question avec autorité ;-)

Pourquoi est-ce std::vector<string> vecCityNames;mauvais?

Le problème avec la notation hongroise telle qu'elle est généralement utilisée est que, si le profilage montre que les noms de villes devraient plutôt être conservés dans un std::deque, tous les noms de variables faisant référence à un objet de ce type auront soudainement un nom trompeur.

Allez-vous renommer toutes vos variables? Avez-vous déjà essayé de le faire dans un grand projet? Avec l'aide de Murphy (et le gars est incroyablement utile là-bas), quelqu'un quelque part aura certainement utilisé des variables appelées quelque chose comme deqCityNames, ce qui rend vos modifications briser la construction, vous laissant assis pendant des heures à tripoter du code que, pendant une demi-décennie, personne n'a osé regarder à, de peur d'être mordu par une bête venimeuse.

D'après ce que je sais, cependant, la façon dont Charles Simonyi a conçu le hongrois, le préfixe désignait l' utilisation sémantique des variables plutôt que son type syntaxique . Autrement dit, le préfixe approprié pour votre liste de noms de villes, quel que soit le type dans lequel il est implémenté, serait probablement listCityNames(ou lstCityNames, s'il listn'est pas assez cryptique pour vous).

Mais je considère ce préfixe tout à fait superflu, car le pluriel ("noms") indique déjà qu'il s'agit d'un tas de villes. Conclusion: lorsque vous choisissez vos identifiants avec soin, la notation hongroise est rarement nécessaire. OTOH, la façon dont il est communément utilisé, à long terme, endommage réellement le code.

Pour une raison quelconque, les réponses existantes semblent danser autour de la justification de la notation hongroise, sans l'énoncer clairement. La notation hongroise est utile pour ajouter des informations de type (dans un sens théorique de type ) lorsqu'il serait difficile de le faire dans la langue elle-même . En l'occurrence, il n'est généralement pas si difficile d'utiliser C ++ ou le système de type Java de telle manière que la notation hongroise (comme généralement décrite) est complètement superflue, et c'est probablement ce qui a conduit à un retour de bâton contre elle - cela ajoute du travail de programmeur pour maintenir ces annotations dans toutes nos variables naes, mais fournit peu ou pas de valeur supplémentaire (et peut même causer des dommages, car le code semble plus encombré).

D'un autre côté, si l'on restreint l'utilisation de la notation hongroise pour taper des informations (encore une fois, dans un sens théorique de type ) qui n'est pasnaturellement encapsulé par la langue, alors il peut être très utile. Par exemple, C et C ++ transmettent les références de tableau en tant que types de pointeurs, mais les références de tableau et les pointeurs ont des opérations différentes qui doivent être effectuées contre eux: les tableaux peuvent être indexés au-delà du premier élément, contrairement aux pointeurs. Il s'agit d'informations utiles qui sont perdues pour le système de types dès qu'un tableau est passé à une fonction comme argument. En tant que tel, dans notre groupe, nous avons adopté des annotations de nom de variable dans le code C et C ++ pour distinguer si une variable de pointeur est en fait un pointeur vers un seul élément ou un pointeur vers un tableau. L'adoption de cette convention a été en partie responsable d'une forte réduction de l'occurrence de problèmes de corruption de mémoire dans notre base de code.

Ça agace certaines personnes (aucune idée pourquoi)

La raison pour laquelle cela m'énerve, c'est que c'est un petit ralentissement sur chaque identifiant unique qui ralentit mon balayage visuel du code. les mAs de sIt si pYou kHad zTo qRead cText iEnglish comme uThis.

La haine est un mot trop fort, OMI. Vous pouvez écrire votre code comme vous le souhaitez; Je préfère simplement ne pas utiliser la notation hongroise dans mon propre code, et étant donné un choix, je préférerais également ne pas avoir à le lire ou à travailler avec lui dans le code d'autres personnes.

Vous avez demandé pourquoi certaines personnes trouvent la notation hongroise ennuyeuse. Je ne peux pas parler pour les autres, mais les raisons pour lesquelles cela m'agace sont:

1. C'est moche. Le hongrois prend des noms parfaitement raisonnables et ajoute ce qui équivaut à un code. Une fois que vous avez internalisé ce code, je suis sûr que c'est parfaitement logique, mais pour les non-initiés, il semble que quelqu'un a déclenché le gestionnaire de noms C ++ sur mon code source.

2. C'est redondant. La déclaration d'une variable établit son type; Je ne ressens pas le besoin de répéter ces informations dans le nom de la variable. Ce n'est pas vrai dans tous les langages: en Perl, par exemple, des sigils tels que @ ou $ ajoutés au nom de la variable définissent essentiellement le type de la variable, vous n'avez donc pas d'autre choix que de les utiliser.

3. Cela résout un problème que je n'ai pas. Les méthodes et les fonctions ne doivent pas être si longues que vous devez chercher attentivement pour trouver la déclaration d'une variable ou d'un paramètre local, et elles ne doivent pas impliquer autant de variables que vous avez du mal à garder une trace de ce qui est quoi. La déclaration de variables locales proches du code qui les utilise est également utile à cet égard. Les compilateurs C du passé exigeaient que toutes les variables locales soient déclarées au début de la fonction, mais cette limitation a été supprimée depuis longtemps.

4. C'est incomplet. La notation hongroise a été inventée pour une langue (BCPL) qui n'avait pas de système de type, et a ensuite été largement utilisée dans une langue (C) qui avait un nombre assez limité de types natifs. OMI, cela ne fonctionne pas bien avec des langages comme C ++ ou Java qui ont des systèmes de type étendus. Pourquoi voudrais-je utiliser un préfixe pour indiquer le type d'une variable qui est un type natif, comme char [], mais pas une classe? Alternativement, si je commence à inventer des préfixes comme vecpour les classes, je me retrouverai avec une grande hiérarchie de préfixes parallèle à ma hiérarchie de classe. Si cela vous plaît, vous êtes le bienvenu; y penser me donne mal à la tête.

5. C'est ambigu , du moins si je comprends bien. Quelle est la différence entre szFooet pszFoo? Le premier est une chaîne terminée par zéro et le second est un pointeur sur une chaîne terminée par zéro. Mais en C ou C ++, pour autant que je sache, toute variable de chaîne est effectivement un pointeur, sont-elles donc les mêmes ou non? Que dois-je utiliser? La réponse réelle n'a pas vraiment d'importance - le fait est que je ne peux pas discerner la réponse en utilisant la notation même qui est censée m'aider à éviter ce genre de questions. La déclaration de la variable, d'autre part, doit être sans ambiguïté car c'est ce que le compilateur utilise.

Ce sont les choses qui fâchent me au sujet de la notation hongroise. Même en tant que groupe, je ne pense pas qu'ils expliquent pleinement pourquoi le hongrois a été largement abandonné. Voici les trois principales raisons pour lesquelles la plupart des programmeurs n'utilisent pas le hongrois:

1. Il n'y a aucune raison impérieuse de l'utiliser. Voir les points 3 et 4 ci-dessus. Je pourrais probablement vivre avec les ennuis si le hongrois offrait un gros avantage par rapport à ne pas utiliser le hongrois, mais je n'en vois pas, et apparemment la plupart des autres personnes non plus. La meilleure chose à propos du hongrois était peut-être que c'était une convention largement utilisée, et si vous vous en tenez à l'utilisation standard, vous pouvez raisonnablement vous attendre à ce que d'autres programmeurs ayant des compétences similaires soient capables de comprendre la notation.

2. Influence accrue des entreprises qui ne sont pas Microsoft. Il est probablement juste de dire que la plupart des programmeurs qui ont adopté la notation hongroise l'ont fait parce que c'est la façon dont Microsoft a écrit le code, et c'est souvent plus facile de suivre le flux. Des entreprises comme Google et Apple ont des sphères d'influence beaucoup plus grandes maintenant qu'elles ne l'étaient dans le passé, et plus de programmeurs que jamais adoptent les styles de ces sociétés et d'autres qui évitent principalement le hongrois. (Il est juste de souligner que vous voyez toujours des restes, par exemple, Google et Apple utilisent souvent un préfixe «k» pour les noms constants.)

3. Microsoft lui-même a abandonné le hongrois. Si vous consultez la section Conventions générales de dénomination de Microsoft de ses directives de codage, vous constaterez qu'il est indiqué en gras: N'utilisez pas la notation hongroise.

Par conséquent, une raison valable d'arrêter d'utiliser la notation hongroise est:

La popularité de la notation hongroise a diminué au point que la convention n'est plus utile. Beaucoup moins de programmeurs utilisent ou même comprennent le hongrois de nos jours, et la convention est donc beaucoup moins efficace pour transmettre les informations qu'elle est censée utiliser. Si vous trouvez que c'est un moyen utile d'écrire du code dans vos propres projets personnels, il n'y a pas de raison de s'arrêter. Cependant, si vous écrivez du code au sein d'une équipe qui n'utilise pas le hongrois, cela peut devenir un mur entre vous et le reste de l'équipe au lieu d'une stratégie de communication réussie.

Jusqu'à présent, je vois les avantages suivants à l'utiliser:

• Dénomination cohérente des variables

Si je nomme toutes mes variables d'après des personnages des Simpsons, c'est cohérent aussi, mais est-ce un avantage?

• Vous voyez le type sans rechercher (intellisense est mort / indexé la moitié du temps, donc c'est toujours une raison valable)

C'est la seule raison valable, basée sur la faiblesse d'un outil spécifique ...

• La sémantique peut toujours être intégrée dans la deuxième partie du nom

Ce n'est pas un avantage; vous prétendez simplement l'absence d'un inconvénient ( massif ).

L'IDE me dira trivialement quel est le type d'une variable quand je la survole. Alors, pourquoi prendre la peine de dupliquer ces informations? Fondamentalement, la notation hongroise des systèmes est une violation de DRY, avec tous les pièges qui y sont associés. Lorsque ces informations sont trivialement accessibles dans un environnement moderne, il n'y a aucune raison de payer ce prix.

La cohérence n'est pas un avantage en soi. Ne pas les nommer avec le type est également cohérent. Vous n'auriez d'incohérence que si certaines variables avaient leur type dans le nom. Et empaqueter la sémantique dans la deuxième partie est simplement "Eh bien, ce n'est pas si mal.", Tout le monde peut utiliser le nom entier pour la sémantique. Vous n'avez aucun réel avantage répertorié.

Un autre point avec les formes traditionnelles de la notation hongroise est qu'il s'agit généralement de préfixes. il y a 2 problèmes à mon humble avis ici:

1) Un lecteur humain aimerait généralement les informations les plus importantes en premier, dans la plupart des formes de hongrois, les informations encodées sont sans doute moins importantes que le nom lui-même.

2) Les préfixes effectuent le tri lexical, donc si, par exemple, vous allez utiliser un préfixe pour désigner des interfaces ou des classes et que votre IDE en fournit une liste triée, les classes / interfaces associées vont être séparées dans cette liste.

De toute évidence, cela se résume à des opinions, il sera donc difficile de travailler avec des faits ici. Personnellement, je trouve que l'argument de la notation hongroise est un peu mince dans les langages orientés objet fortement typés. D'après mon expérience, les applications OO ont tendance à gérer la complexité en gardant les classes cohérentes et concises, et la même chose peut être dite à propos des fonctions. Cela signifie que toutes choses étant égales par ailleurs, vous vous retrouvez avec:

• Plus de classes / types
• Méthodes plus courtes

Maintenant, si vous souhaitez utiliser la notation hongroise, vous devez décider de l'appliquer à tous les niveaux, ou de simplement l'utiliser pour certains types et classes privilégiés (tels que les classes de bibliothèque de base). Ce dernier n'a aucun sens pour moi, et le premier mène au «labyrinthe d'essayer de trouver différentes abréviations pour mille types différents» auquel faisait référence Péter Török. Cela signifie qu'il existe un surcoût important dans la gestion des listes d'abréviations, et généralement "la dénomination variable cohérente" sort par la fenêtre.

Le deuxième point sur les méthodes plus courtes signifie que dans la plupart des cas, vous n'aurez pas à parcourir des centaines de lignes de code pour vérifier de quel type est une variable. Nommer les variables un peu plus soigneusement éliminerait certaines de vos autres questions - par exemple par cityNamerapport à juste city. J'espère que ce cityNamen'est pas un flotteur :)

Quant à savoir pourquoi cela agace les gens - encore une fois, cela est probablement dû à son habitude ou non. Mais en tant que personne qui n'y est pas habituée, je peux vous dire que l'utilisation de la notation hongroise brise le flux de code pour mes yeux, ce qui rend la lecture plus difficile. Pour résumer, je ne dis pas qu'il n'a aucun mérite (bien que je n'ai pas discuté de certains de ses inconvénients, en termes de refactoring, etc.), je dis que l'effort ne vaut pas la peine, pour les langages OO fortement typés.

Je ne sais pas dans le contexte de C ++ mais dans le monde Java / C #, je préférerais de loin avoir des noms significatifs qui véhiculent soit un langage de domaine ou un contexte que de me dire que strFirstNamec'est une chaîne; il devrait être évident qu'il s'agit d'une chaîne, ou le nom doit être refactorisé pour exprimer une meilleure intention. Si vous avez besoin d' un préfixe pour connaître le type de ce avec quoi vous travaillez, je dirais que votre nom est incohérent, pas suffisamment descriptif ou carrément faux. Dans les langues modernes, je préfère toujours les noms plus longs qui ne laissent aucune ambiguïté que les noms vagues ou ambigus.

La seule fois où j'utilise le hongrois est pour les contrôles ASP.NET, et c'est d'autant plus vrai que IA) n'a pas à taper quelque chose de très long comme CustomerFirstNameTextBoxcontre txtCustomerFirstName, et B) Donc Intellisense triera tous les types de contrôle. Je me sens "sale" même en faisant cela, cependant, je n'ai pas encore trouvé de meilleur moyen.

Meh - il s'agit vraiment de préférences personnelles, peu importe à quel point on essaie de rationaliser ses choix. Personnellement, je m'en tiens à la règle "Quand à Rome ..." et j'utilise le hongrois dans du code qui appelle beaucoup l'API Windows. Pour le code indépendant de la plate-forme, j'ai tendance à suivre le style de bibliothèque standard C ++.

La réponse réside dans cette question: dites-moi comment nommer les variables suivantes:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

Ajoutez à ces chaînes constantes, pointeur vers celles-ci et pointeurs constants vers celles-ci.

Je n'aime pas du tout la forme de notation hongroise que vous décrivez. La raison? Cela ne sert à rien 90% du temps.

Par exemple, un peu de code (C ++ équivalent écrit en Delphi) d'un projet hérité que je suis obligé de supporter:

pRecords[0]->FooMember=10;

... pRecord est une variable, elle est de type TRecordList. TRecordList *pRecords[10];

C'est une classe composée d'une propriété nommée FooMember qui pointe vers fFooMember ... ou mFooMember selon qu'il s'agit d'un "champ" ou d'un "membre" (indice: c'est la même chose)

Problèmes? fFooMemberpourrait être quelque chose comme FooMember_ car nous y accèderons toujours via la propriété publique FooMember. pRecords? Il est assez évident que c'est un pointeur du fait que vous le déréférencez partout. TRecordList? Quand pouvez-vous éventuellement confondre un nom de type et un objet de ce type? Le compilateur vous crie dessus et les types ne sont utilisés quasiment pas dans les objets (sauf pour les propriétés / méthodes statiques)

Maintenant, il y a un endroit où j'utilise la notation hongroise. C'est lorsque vous traitez de nombreuses variables d'interface utilisateur qui auraient le même nom que d'autres variables d'interface utilisateur ou des variables régulières.

Par exemple, si j'avais un formulaire pour votre prénom dessus.

J'aurais une classe nommée FirstNameForm. À l'intérieur, lblFirstName et txtFirstName pour l'étiquette et la zone de texte respectivement. Et une propriété FirstName publique pour obtenir et définir le nom dans la zone de texte.

Cela pourrait également être résolu en utilisant FirstNameLabel et FirstNameTextBox mais je trouve que cela prend du temps à taper. Surtout avec quelque chose comme GenderDropDownList et autres.

Donc, fondamentalement, la notation hongroise est, au mieux, ennuyante au niveau systématique et le pire des cas nuisible (comme les autres réponses donnent des problèmes de refactorisation et de cohérence).