Sinn und Unsinn der ungarischen Notation

Jester

Mr Evil schrieb:

ich les immer von geringerer lesbarkeit - das ist doch bloedsinn - durch UN ist es nicht weniger lesbar als ohne, ich find es ist dadurch sogar noch besser lesbar

aber klar doch paulWeights ist prima lesbar, handelt es sich doch nicht etwa um Pauls Gewichtsdaten, wie der unbedarfte Leser vielleicht annehmen könnte, sondern um einen "pointer to array of unsigned long" names Weights. Das steigert die Lesbarkeit natürlich enorm.

rüdiger

Mr Evil schrieb:

also wenn ich hier mal wieder {eigentlich taeglich} code durchlesen, und ich wuerde nicht gleich erkennen obs eine member ist - und was fuer ein typ usw, ich wuerde durchdrehen - muesste ich alles viel aufwendiger durchsehen

Dann scheinen die Probleme eher woanders zu liegen. Globale Variablen, zu lange Funktionen/Methoden oder printf-Style-APIs, wo man den Typ selbst wissen muss etc.

Normalerweise interessiert der konkrete Typ doch nicht.

EXDW

Jester schrieb:

aber klar doch paulWeights ist prima lesbar, handelt es sich doch nicht etwa um Pauls Gewichtsdaten, wie der unbedarfte Leser vielleicht annehmen könnte, sondern um einen "pointer to array of unsigned long" names Weights. Das steigert die Lesbarkeit natürlich enorm.

Das beispiel ist doch hirnrissig, wenn ein pointer zum array dann
paWeights
zudem handhaben wir das alles so der der bezeichner am anfang klein geschrieben wird, und der selbstname gross beginnt
pointer to array von weights waere wie gesagt
paWeights
und wenn es paulas gewicht ist
paPaulaWeights
es sind in diesem fall 2 zeichen mehr die direkt erkennen lassen was die variable ist - ich seh da kein problem

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.