Sinn und Unsinn der ungarischen Notation

byto

Der Mehraufwand beim Refactoring würde mich aber ziemlich nerven. Und wenn mal jemand zu faul ist und den Namen bei Typänderung nicht ändert, ist das Chaos komplett. Darüber hinaus interessiert der Typ nicht, wenn man Code einfach nur bzgl. der Fachlichkeit "lesen" will.

CStoll

Wieso reiten hier immer noch alle auf dem "Typ" herum? Der Typ einer Variable steht in der Definition, den brauchst du nicht noch im Namen zu codieren - die eigentliche Funktion der UN war es, die Aufgabe der Variablen zu kennzeichnen.

Apollon

Was im Grunde genauso obsolet ist, weil der Name es andeutet.

tfa

Apollon schrieb:

Was im Grunde genauso obsolet ist, weil der Name es andeutet.

Genau. Die UN wird obsolet durch sinnvolle Namenswahl. So einfach ist das.

byto

CStoll schrieb:

Wieso reiten hier immer noch alle auf dem "Typ" herum? Der Typ einer Variable steht in der Definition, den brauchst du nicht noch im Namen zu codieren - die eigentliche Funktion der UN war es, die Aufgabe der Variablen zu kennzeichnen.

Weil sich alle Beispiele hier immer auf den Typ beziehen (siehe paWeights).
Wie sehen denn dann solche Präfixe/Suffixe der UN aus, die die Aufgabe der Variable beschreiben? Ich wüsste nicht, wie man die fachliche Aufgabe einer Variable sinnvoll kodiert, ohne dabei alle anderen zu verwirren oder den Code unleserlich zu machen. Wenn ich ein Fachbuch lese, möchte ich auch nicht in jedem Satz 37 Abkürzungen haben, selbst wenn ich Ihre Bedeutung kenne.

CStoll

byto schrieb:

Weil sich alle Beispiele hier immer auf den Typ beziehen (siehe paWeights).

Ja, mit "typunabhängigen" Kürzeln kannst du auch nur schwer erklären, daß die Typinformation nichts im Namen zu tun hat

Wie sehen denn dann solche Präfixe/Suffixe der UN aus, die die Aufgabe der Variable beschreiben?

z.B. i für Index (das kann int, long oder size_t sein) oder a für Array (aus logischer Sicht - muß also nicht unbedingt ein C-Array sein). In den meisten Fällen definiert die Aufgabe der Variable schon eine Einschränkung der möglichen Typen (den Namen einer Person packt man in einen "String", ihr Alter in eine "Zahl") - und sonst würde ich eher anwendungsspezifische Präfixe verwenden, z.B. cw vs. cs (Koordinaten bezogen auf Fenster- vs. Bildschirm).

Jester

Mr Evil schrieb:

Das beispiel ist doch hirnrissig, wenn ein pointer zum array dann
paWeights

Aber dann ist es doch völlig unleserlich, woher soll man da auf einen Blick wissen, dass es ein array von unsigned long ist?

CStoll

Jester schrieb:

Mr Evil schrieb:

Das beispiel ist doch hirnrissig, wenn ein pointer zum array dann
paWeights

Aber dann ist es doch völlig unleserlich, woher soll man da auf einen Blick wissen, dass es ein array von unsigned long ist?

Wie die Gegner der UN hier ständig erklären - daß es 'unsigned long' Werte sind, ist völlig irrelevant (selbst das p wäre imho redundant) - wichtig ist bestenfalls, daß es ein Array von numerischen Werten ist (ob hinter "Array" ein C-Array, std::vector<> oder MFC's CArray bzw. hinter "numerischer Wert" ein unsigned long, int, double oder was selbstdefiniertes steckt, ist austauschbar - und muß/darf nicht im Namen einkodiert werden).

byto

Dann kann ich auch einfach "weights" schreiben. Die Mehrzahl sagt alles und es bleibt leserlich. Und ich kriege auch keine Probleme, wenn z.B. mal aus dem Array eine Linked List wird.

groovemaster

CStoll schrieb:

Wie sehen denn dann solche Präfixe/Suffixe der UN aus, die die Aufgabe der Variable beschreiben?

z.B. i für Index (das kann int, long oder size_t sein)

Mal abgesehen davon, dass ich mich hier fragen würde, ob das i nun für Index, int, Iterator oder was auch immer steht, welchen konkreten Nutzen hast du davon?

CStoll schrieb:

oder a für Array (aus logischer Sicht - muß also nicht unbedingt ein C-Array sein).

Es gibt unzählige Container, Arrays, Sequenzen, Listen, Maps, Queues, Stacks, etc.pp. Wer soll denn da bitteschön durchblicken? Mich interessiert hier doch lediglich eines, welche Member stehen mir zur Verfügung. Bzw. was kann ich mit diesem Container anfangen. Und dazu reicht maximal ein Blick auf die Deklaration, um den Typ zu erfahren. Über die genaue Funktionsweise des Containers sagt so ein Präfix auch nichts aus. Dann heisst es, sich die entsprechende Doku durchzulesen.

rüdiger

Tim schrieb:

Ich verstehe nur nicht, was falsch daran sein soll einer (globalen) Variable z.B. das prä/postfix "angle" oder sowas mitzugeben. Halt einen Qualifier nach einer Konvention.

Edit: Als präfix finde ich das aber auch nicht toll.

Nicht jede einheitliche Namenskonvention würde ich als UN bezeichnen. Da spricht sicher nichts gegen. Wobei man im OO-Sinne auch darauf achten sollte, dass sich Typen entsprechend eines Konzeptes verhalten.

CStoll

groovemaster schrieb:

CStoll schrieb:

Wie sehen denn dann solche Präfixe/Suffixe der UN aus, die die Aufgabe der Variable beschreiben?

z.B. i für Index (das kann int, long oder size_t sein)

Mal abgesehen davon, dass ich mich hier fragen würde, ob das i nun für Index, int, Iterator oder was auch immer steht, welchen konkreten Nutzen hast du davon?

Ich sehe auf einen Blick, was die Aufgabe der Variablen ist (besonders wenn der Name zu dem Datenfeld passt, in das ich indizieren will - iNamesXyz ist ein Index, der sich auf das Array aNames bezieht).
(btw, 'int' hat bei der Namenswahl nichts zu suchen (wäre bestenfalls n (numerisch), Iteratoren würde ich mit p kennzeichnen.

CStoll schrieb:

oder a für Array (aus logischer Sicht - muß also nicht unbedingt ein C-Array sein).

Es gibt unzählige Container, Arrays, Sequenzen, Listen, Maps, Queues, Stacks, etc.pp. Wer soll denn da bitteschön durchblicken? Mich interessiert hier doch lediglich eines, welche Member stehen mir zur Verfügung. Bzw. was kann ich mit diesem Container anfangen. Und dazu reicht maximal ein Blick auf die Deklaration, um den Typ zu erfahren. Über die genaue Funktionsweise des Containers sagt so ein Präfix auch nichts aus. Dann heisst es, sich die entsprechende Doku durchzulesen.

Und wo ist das Problem? Ich betrachte "Array" nicht im Sinne eines C-Arrays, sondern abstakter als einen Container, auf den ich über Index zugreifen kann (std::vector, std::deque, CObArray etc), Container mit eingeschränkten Zugriffsmöglichkeiten bekommen ihre eigenen Kürzel (z.B. ls für list<>artige oder mp für Maps).

@byto: Hinter "Weights" kann wahlweise ein struct (mit Leergewicht, Maximalgewicht etc eines Objekts) oder ein Array (mit Gewichten verschiedener Gegenstände) stehen.

Helium

foo = bar[baz];

Verdammt was könnte dieser Coede blos bedeuten? Keine Ahnung, da könnte echt mal jemand sowas, wie i und a dran schreiben

foo = aBar[iBaz];

Ah, jetzt verstehe ich den Code endlich.

Artchi

Hallo

Helium schrieb:

foo = bar[baz];
Verdammt was könnte dieser Coede blos bedeuten? Keine Ahnung, da könnte echt mal jemand sowas, wie i und a dran schreiben
foo = aBar[iBaz];
Ah, jetzt verstehe ich den Code endlich.

Sehr schön. Das fasst die Diskussion gut zusammen.

chrische

chrische5 schrieb:

Hallo

Helium schrieb:
foo = bar[baz];
Verdammt was könnte dieser Coede blos bedeuten? Keine Ahnung, da könnte echt mal jemand sowas, wie i und a dran schreiben
foo = aBar[iBaz];
Ah, jetzt verstehe ich den Code endlich.
Sehr schön. Das fasst die Diskussion gut zusammen.

chrische

Es fasst vor allem das Niveau der Diskussion gut zusammen.

Tim schrieb:

Es fasst vor allem das Niveau der Diskussion gut zusammen.

diese 'diskussion' erinnert verdächtig an das, was man in NADRW immer so vorgesetzt bekommt.

DEvent

Helium schrieb:

foo = bar[baz];
Verdammt was könnte dieser Coede blos bedeuten? Keine Ahnung, da könnte echt mal jemand sowas, wie i und a dran schreiben
foo = aBar[iBaz];
Ah, jetzt verstehe ich den Code endlich.

Noch nie wurden die Geister so gespalten wie bei den U-Notation. Ob der Ungar sich das so vorgestellt hatte? Er wollte die Welt nur bereichern, wollte die Welt zu einem besserem Ort machen, nach seinen Vorstellungen. Wer konnte ahnen das im Jahre 2008 der Disput so einen tragischen Ausgang nehmen wuerde: Der Erste Ungarische-Notation-Weltkrieg.

Ausgeloest von einem Chat im #cpp Channel konnte ein Anhaenger dieser grandiosen Ungarischen Notationen nicht mehr die Schmaelungen seitens der Ahnunglosen hinnehmen. Niemand in diesem Channel konnte ja auch Ahnen das der groesste Fan der U-Notation in einem Stuetztpunkt der USA arbeitet, bei dem er die Aufsicht ueber die Kernwaffen haellt.

Wird dies das Ende der Menschheit sein? Werden unsere Kindeskinder einmal Geschichten hoeren ueber den groessten Disput der 1972-1981 seinen Ursprung nahm? Werden sie es als den groessten Fehler in der Weltgeschichte wahrnehmen?

Und vor allem: Werden diese sinnlosen Threads ueber die noch sinnloserenen U-Notationen endling der Geschichte angehoeren???

DEvent

http://msdn2.microsoft.com/en-us/library/aa260976(VS.60).aspx

if (cch>=2)
         cwSz=(cch-2/sizeof(int)+1;
      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
      Zero((int *)psy,cwSY);
      bltbyte(sz, psy->sz, cch+1);
      return(psy);

Jepp, UN machen alles so viel lesbarer.

thordk

ich finde code mit ungarischer notation grundsätzlich grauslig und unübersichtlich.

grauslig, weil sich in jeden code früher oder später an einer oder mehreren stellen ein bruch findet. da ändert irgendjemand mal kurz eine signatur oder einen typ, vergisst dabei, die prefixe der variablen anzupassen und schon kann man sich im gesamten code nicht mehr darauf verlassen, dass eine variable namens iUpdCmp tatsächlich einen integer beinhaltet.

unübersichtlich, weil dieses prefixgedöns den lesefluss extrem beeinflusst. und klassische c-programmierer neigen dazu, variablen abkürzende namen zu geben (iUpdCmp), die wenig aussagekraft haben, wenn man nicht den gesamten kontext kennt. anstatt sich mit ungarischer notation rumzukloppen, sollte man seinen variablen und methoden einfach anständige und verständliche namen geben. eine methode namens i2c ist vielleicht kurz und spart tipparbeit, aber dieselbe methode in integerToCharacter umbenannt zeigt sofort eindeutig, was sie tun soll. wenn man sich an ungarische notation hält, kann man sie meinetwegen auch characterFromInteger nennen.

musste die letzten wochen sehr viel alten c-code nach java portieren und der grossteil dieses codes war von ungarischer notation verseucht. der code, der einfach anständige bezeichner verwendet hat, war wesentlich schneller zu verstehen und auch zu portieren.