Bons exemples de notation hongroise? [fermé]

Question

Il s’agit de rechercher de bons exemples de notation hongroise pour pouvoir en rassembler une collection.

Modifier: Je suis d'accord pour dire que le hongrois n'est pas nécessaire, mais j'espère des exemples plus spécifiques, dans lesquels il améliore la lisibilité et la maintenabilité, comme Joel le mentionne dans son article (selon ma réponse). ).

Answer 1

L'article désormais classique, mentionné dans d'autres publications hongroises, est celui du site de Joel:

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

Answer 2

Le problème avec demander de bons exemples de notation hongroise est que tout le monde va avoir sa propre idée de ce à quoi ressemble un bon exemple. Mon opinion personnelle est que la meilleure la notation hongroise est pas de hongrois. Notation . La notation était à l’origine destinée à désigner l’utilisation prévue d’une variable plutôt que son type, mais elle est généralement utilisée pour les informations de type, en particulier pour les contrôles de formulaire (par exemple, txtFirstName pour un texte). case pour le prénom de quelqu'un.). Cela rend le code moins facile à gérer, en termes de lisibilité (par exemple, "prepIn nounTerms prepOf nounReadability") et de refactoring lorsque le type doit être modifié (il existe des "lParams" dans l'API Win32 qui ont changé de type).

Vous devriez probablement envisager de ne pas l'utiliser du tout. Exemples:

• strFirstName : il peut s'agir simplement de prénom , car son type n'est pas évident, le type n'est pas si important et devrait l'être dans ce cas. Si ce n’est pas évident, l’EDI peut vous aider.
• txtFirstName : cette option peut devenir FirstNameTextBox ou FirstName_TextBox . Il lit mieux et vous savez que c'est un contrôle et pas seulement le texte.
• CAccount - C a été utilisé pour les noms de classe dans MFC, mais vous n'en avez vraiment pas besoin. Le compte est suffisant. Le nom en majuscule est la convention standard pour les types (et ils n'apparaissent qu'à des endroits spécifiques afin qu'ils ne soient pas confondus avec les propriétés ou les méthodes)
• ixArray (index vers tableau ) - ix est un peu obscur. Essayez arrayIndex .
• usState (chaîne non sécurisée pour État ) - ressemble à "U.S. Etat ". Il vaut mieux utiliser state _ UnsafeString ou quelque chose du genre. Peut-être même l'envelopper dans une classe UnsafeString pour au moins le rendre sûr du type.

Answer 3

p

(pour le pointeur). C'est à peu près le seul préfixe que j'utilise. Je pense que cela ajoute beaucoup à une variable (par exemple que c'est un pointeur) et devrait donc être traité avec un peu plus de respect.

Le hongrois pour les types de données est quelque peu dépassé. Les IDE peuvent vous dire quel est le type (quelques secondes seulement survolant le nom de la variable), ce qui n’est donc pas si important. Mais traiter un pointeur comme si ses données n'étaient pas bonnes, vous voulez donc vous assurer qu'il est évident pour l'utilisateur ce qu'il est même s'il fait des hypothèses qu'il ne devrait pas le faire lors du codage.

Answer 4

t

Données altérées. Préfixez toutes les données provenant d'une source non fiable pour que cette variable soit corrompue. Toutes les données contaminées doivent être nettoyées avant tout travail réel.

Answer 5

Il est inutile d'utiliser le hongrois pour indiquer les types car le compilateur le fait déjà pour vous.

Ce qui est utile en hongrois est de faire la distinction entre des types de variables logiquement différentes qui ont le même type brut. Par exemple, si vous utilisez ints pour représenter des coordonnées, vous pouvez préfixer les coordonnées x avec les coordonnées x, y avec y et les distances avec d. Donc, vous auriez un code qui ressemble à

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

et ainsi de suite. C'est utile car vous pouvez repérer les erreurs d'un coup d'œil: si vous ajoutez un colorant à un y, vous obtenez toujours un y. Si vous soustrayez deux x, vous obtenez toujours un dx. Si vous multipliez un dy par un scalaire, vous obtenez toujours un dy. Etc. Si vous voyez une ligne comme

yTop = dyText + xButton

vous savez d'un coup d'œil que c'est faux, car ajouter un dy et un x n'a pas de sens. Le compilateur n’a pas pu saisir cela pour vous car, autant que cela est possible, vous ajoutez un int à un int, ce qui est correct.

Answer 6

N'utilisez pas de préfixes spécifiques à une langue.

Nous utilisons:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

Nous utilisons le même système pour toutes les langues:

SQL
C
C#
Javascript
VB6
VB.net
...

C'est un épargnant de vie.

Answer 7

L'Avocat du diable: Le meilleur exemple de notation en hongrois est de ne pas l'utiliser. : D

Nous n’avons aucun avantage à utiliser la notation hongroise avec les IDE modernes car ils en connaissent le type. Cela ajoute du travail lors de la refactorisation d'un type pour une variable car le nom devrait également être changé (et la plupart du temps lorsque vous utilisez une variable, vous savez de quel type il s'agit de toute façon).

Vous pouvez également entrer dans les problèmes de commande avec la notation. Si vous utilisez p pour pointeur et a pour adresse, appelez-vous votre variable apStreet ou paStreet? La lisibilité diminue lorsque vous n'êtes pas cohérent et vous devez utiliser un espace mental précieux lorsque vous devez vous rappeler l'ordre dans lequel vous devez écrire la notation.

Answer 8

Je trouve que la notation hongroise peut parfois être utile dans les langages dynamiques. Je pense en particulier à ServerScript Actionscript (essentiellement du javascript), mais cela pourrait s'appliquer ailleurs. Puisqu'il n'y a pas du tout d'informations de type réel, la notation hongroise peut parfois aider à rendre les choses un peu plus faciles à comprendre.

Answer 9

Le seul Hongrois qui soit vraiment utile est m_ pour les variables membres. (J'utilise aussi sm_ pour les membres statiques, car c'est la "autre" portée qui existe toujours). Avec les moniteurs à écran large et les compilateurs prenant des noms de variable longs de 8 milliards de caractères, les noms de type abrégés n'en valent simplement pas la peine.

Answer 10

La notation hongroise (le chameau, comme je l’ai appris) est inestimable lorsque vous héritez d’un projet logiciel.

Oui, vous pouvez survoler une variable avec votre IDE et découvrir de quelle classe il s'agit. Toutefois, si vous parcourez plusieurs milliers de lignes de code, vous ne voulez pas vous arrêter pendant ces quelques secondes - chaque .... seul .... temps ....

N'oubliez pas que vous n'écrivez pas de code pour vous ou votre équipe. Vous écrivez également cela pour la personne qui doit récupérer ce code dans les 2-5 ans et l’améliorer.

Answer 11

J’étais fermement opposé à la notation hongroise jusqu’à ce que j’ai vraiment commencé à lire à ce sujet et à essayer de comprendre son intention originale.
Après la lecture de Joels, le message " Wrong " et l'article "Redécouverte de la notation hongroise". J'ai vraiment changé d'avis. Fait correctement, je pense qu'il doit être extrêmement puissant.

Wrong par Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html

Redécouvrir la notation hongroise
http://codingthriller.blogspot.com/2007/11/rediscovering- Hungarian-notation.html

Je crois que la plupart des opposants ne l’ont jamais réellement essayé et ne le comprennent pas vraiment. J'aimerais bien l'essayer dans un vrai projet.

Answer 12

Je pense que l'élément clé à retenir de l'article de Joel (lien ci-dessus) et de la notation hongroise en général est de l'utiliser lorsque la variable présente un caractère non évident.

Un exemple, tiré de l'article, est codé par rapport à des chaînes non codées. Ce n'est pas que vous devriez utiliser "nous" en hongrois pour les chaînes non sécurisées et "s" pour les chaînes sécurisées, mais plutôt en identifiant pour indiquer qu'une chaîne est sécurisée ou non. Si cela devient la norme, il devient facile de voir quand la norme est dépassée.

Answer 13

m

Lorsque vous utilisez un ORM (tel que le mode Veille prolongée), vous avez tendance à traiter des objets gérés et non gérés. La modification d'un objet géré sera reflétée dans la base de données sans appeler une sauvegarde explicite, tandis que le traitement d'un objet géré nécessite un appel de sauvegarde explicite. La manière dont vous traitez avec l’objet sera différente selon ce qu’il est.

Answer 14

Je trouve que le seul point utile est la déclaration des contrôles d'interface, txtUsername, txtPassword, ddlBirthMonth. Ce n’est pas parfait, mais cela aide les gros formulaires / projets.

Je ne l'utilise pas pour les variables ou d'autres éléments, mais uniquement pour les contrôles.

Answer 15

En plus d'utiliser "p" pour le pointeur, j'aime bien l'idée d'utiliser "cb" et "cch" pour indiquer si un paramètre de taille de mémoire tampon (ou une variable) est un nombre d'octets ou un nombre de caractères (j'ai également vu - rarement - 'ce' utilisé pour indiquer un nombre d'éléments). Ainsi, au lieu de transmettre le type, le préfixe indique l’utilisation ou l’intention.

J'avoue que je n'utilise pas le préfixe aussi régulièrement que je devrais le faire, mais j'aime bien l'idée.

Answer 16

Je conviens que la notation hongroise n’est plus particulièrement utile. Je pensais que son intention initiale était d'indiquer non pas le type de données, mais plutôt le type d'entité. Dans une section de code impliquant les noms des clients, des employés et de l'utilisateur, par exemple, vous pouvez nommer les variables de chaîne locales cusName, empName et usrName. Cela aiderait à distinguer les noms de variables à consonance similaire. Les mêmes préfixes pour les entités seraient utilisés dans toute l'application. Toutefois, lorsque vous utilisez OO et que vous utilisez des objets, ces préfixes sont redondants dans Customer.Name, Employee.Name et User.Name.

Answer 17

Le nom de la variable doit décrire en quoi elle consiste. Une bonne désignation de variable rend la notation hongroise inutile.

Cependant, vous utiliserez parfois la notation hongroise en plus d’une bonne dénomination des variables. m_numObjects a deux " préfixes: " m_ et num. m _ indique l'étendue: il s'agit d'un membre de données lié à this . num indique la valeur .

Je ne me sens pas du tout gêné lorsque je lis "bien". code, même s’il contient des "Hongrois". Droite: je lis le code, je ne clique pas dessus. (En fait, je n’utilise presque jamais ma souris pour coder, ni pour aucune fonction de recherche spécifique à la programmation voodoo.)

Je suis ralenti quand je lis des choses comme m_ubScale ( oui, je vous regarde, Liran! ), car je dois regarder son utilisation (sans commentaires!) pour savoir ce que il évolue (si du tout?) et son type de données (qui se trouve être un caractère à virgule fixe). Un meilleur nom serait m_scaleFactor ou m_zoomFactor, avec un commentaire sous la forme d'un nombre à virgule fixe ou même une typedef. (En fait, une typedef serait utile, car il existe plusieurs autres membres de plusieurs classes qui utilisent le même format à virgule fixe. Cependant, certains ne le font pas, mais sont toujours étiquetés m_ubW Whatever! Pour le moins déroutant.)

Je pense que le hongrois était censé être un additif au nom de la variable, et non un substitut d'informations. De plus, la notation hongroise n’ajoute souvent rien à la lisibilité de la variable, au gaspillage d’octets et au temps de lecture.

Seulement mes 2 ¢.

Answer 18

Une très vieille question, mais voici quelques "Hongrois". les préfixes que j'utilise régulièrement:

  

mon

     

pour les variables locales, pour distinguer la localité où le nom peut avoir un sens dans un contexte global. Si vous voyez myFoo, il n’est utilisé que dans cette fonction, indépendamment de tout ce que nous faisons avec Foos ailleurs.

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

et

  

tmp

     

pour les copies temporaires de valeurs dans des boucles ou des opérations à plusieurs étapes. Si vous voyez deux variables tmpFoo à plus de deux lignes l'une de l'autre, elles ne sont presque certainement pas liées.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

et parfois old et new pour des raisons similaires à celles de tmp , généralement dans des boucles ou des fonctions plus longues.

Answer 19

Je n'utilise jamais p que pour un pointeur, et c'est tout. Et ce n'est que si je suis en C ++. En C #, je n'utilise aucune notation hongroise. par exemple

MyClass myClass;
MyClass* pMyClass;

C'est tout:)

Modifier: Oh, je viens de réaliser que c'est un mensonge. J'utilise " m_ " pour les variables membres aussi. par exemple

class
{
private:
bool m_myVar;
}

Answer 20

Eh bien, je l’utilise uniquement avec des variables de contrôle de fenêtre. J'utilise btn_, txt_, lbl_ etc. pour les repérer. Je trouve également utile de rechercher le nom du contrôle en saisissant son type (btn_ etc).

Answer 21

Il n’existe pas de bon exemple de la notation hongroise. Juste ne l'utilisez pas. Pas même si vous utilisez un langage faiblement typé. Vous vivrez plus heureux.

Mais si vous avez vraiment besoin d'une raison de ne pas l'utiliser, voici ma préférée, extraite de this excellent lien :

Un autre problème de la notation hongroise consiste à "changer le type d'une variable mais à ne pas modifier le nom de la variable". Ceci est presque toujours fait dans les applications Windows avec la migration de Win16: - WndProc (HWND hW, WORD wMsg, WORD wParam, LONG lParam) vers Win32 WndProc (HWND hW, UINT wMsg, WPARAM wParam, LONG lParam) vers Win32 WndProc (w HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) que ce sont des mots, mais ils se réfèrent vraiment aux longs. La valeur réelle de cette approche apparaît clairement avec la migration Win64, lorsque les paramètres auront une largeur de 64 bits, mais le vieux "w" et " l " les préfixes resteront pour toujours.

Answer 22

Je me trouve à utiliser 'w' qui signifie 'travail', comme préfixe à la place de 'temp' ou 'tmp', pour les variables locales qui ne sont là que pour contourner les données, comme:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function