Wie das T in Delphi - von Ungarischer Notation, Designfehlern und Construktoren

[Kyuu]

Da in diesem Thread die Frage aufgekommen ist, ob die Ungarische Notation sinnvoll ist, greife ich mal dieses Thema hier auf.

Viele, die diese Konvention befürworten, aber auch viele, die sie kritisieren, wissen nicht, dass Ungarische Notation nicht gleich Ungarische Notation ist, es also gravierende Unterschiede gibt. Joel Spolsky erläutert in Making Wrong Code Look Wrong, wie die Ungarische Notation ursprünglich gedacht war und wie sie missverstanden wurde (der sich darauf beziehende Abschnitt ist "I'm Hungary", die anderen sind aber auch lesenswert).

[R.D.]

Wenn ich das richtig verstanden habe soll die Ungarische Notation Varibalen-TYPEN genauer beschreiben? (Damit ich mir mal ne Meinung dazu bilden kann xD)

[Kyuu]

Bei Apps Hungarian ist die Art der Variable interessant, nicht der Typ. Allerdings gibt man seinen Variablen in den meisten Fällen sowieso Namen, aus denen die Bestimmung ersichtlich ist. Am besten gänzlich auf die Ungarische Notation verzichten, denn der Aufwand zahlt sich nur in sehr seltenen Fällen überhaupt aus.

[Owly]

@R.D.: Jein. Genauer beschreiben ist wohl der falsche Ausdruck, vielmehr soll gekennzeichnet werden, welchen Datentyp eine Variable überhaupt hat, damit man sie im Laufe des Programms nicht falsch verwendet.
Edit: Okay, ich schreibe viel zu langsam :P.

So im Detail kannte ich die ungarische Notation gar nicht. Ich habe sie nur im Sinne der Datentypenkennzeichnung in der Berufsschule gelernt/anwenden müssen. Ohne den Artikel (dessen Link ich gerne behalten hätte :/) genauestens studiert zu haben; ein Bekehrter werde ich nicht mehr. Des Datentyps bin ich mir stets bewusst (natürlich auch Dank den modernen Entwicklungsumgebungen) und eine Bezeichnung der Aufgabe ergibt sich für mich direkt aus dem Variablennamen.
Vielleicht sehe ich als Java- und C#- Entwickler die Sache einfach anders, als es jemand tut, der in einer weniger streng typisierten Sprache programmiert.

[Kyuu]

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack.

...

Etwas überspitzt, aber mit Wahrheitsgehalt. Gemeint ist Systems Hungarian.

Des Datentyps bin ich mir stets bewusst (natürlich auch Dank den modernen Entwicklungsumgebungen) und eine Bezeichnung der Aufgabe ergibt sich für mich direkt aus dem Variablennamen.

...

Genau so ist es.
Ich kann mir durchaus einige sinnvolle Anwendungen für die Ungarische Notation vorstellen.
Für Apps Hungarian, wenn viele Programmierer gleichzeitig an einem Projekt arbeiten und jeder eigene Vorstellungen davon hat, wie Bezeichner auszusehen haben. In diesem Fall ist ein Standard erforderlich und Apps Hungarian, oder eine Abwandlung davon könnte erfolgsversprechend angewendet werden.
Oder für Systems Hungarian, wenn man mit einer dynamisch typisierten Sprache zu tun hat und der Code komplex genug ist, um die zusätzlich kodierten Typinformationen im Bezeichner zu rechtfertigen.
Aber in den meisten Fällen und besonders für Hobbyprogrammierer ist die Ungarische Notation nur unnötiger Ballast, teilweise schwer zu lesen, bringt Wartungs- und Migrationsprobleme mit sich und sollte vermieden werden. Zudem ist das Konzept sowieso überholt, da heutige Compiler viel bessere Typsysteme haben als zur Blütezeit der Ungarischen Notation, moderne Editoren Hervorhebung unterstützen und in objektorientierten Sprachen hat es es sowieso wenig verloren.

[R.D.]

Ok, verstanden.
Na gut, dann ist es wie Kyuu sagt. Wenn man im Team arbeitet, kann das durchaus von Vorteil sein. Aber wenn ich was progge, dann lege ich mir die Namen so zurecht, das ich sie auch nach einem Monat noch nachvollziehen könnte. (Was MEIßT klappt^^)

[Jesus_666]

Das Problem ist, daß es oft problematisch ist, ungarische Notation zu verwenden, ohne allzu generisch zu werden oder einen Riesenhaufen Buchstabensalat zu haben.

Nehmen wir an, ich habe eine Instanz der Klasse Array (namens customerBase), die eine Liste von Pointern auf Instanzen der Klasse CustomerGroup beinhaltet, die wiederum (ohne Pointer) Listen von Instanzen der Klasse PayingCustomer beinhalten. Wie notiere ich das?

lCustomerBase, weil es eine lokale Variable ist?
oCustomerBase, weil es ein Objekt ist?
aCustomerBase, weil es ein Array ist?
cbaseCustomerBase, weil es CustomerBase-Instanzen beinhaltet?
paycustCustomerBase, weil es PayingCustomer-Instanzen beinhaltet?

Um komplett zu beschreiben, was die Variable beinhaltet, müßte ich folgendes schreiben:
lOACbasePaycustCustomerBase
Das ist zwar deskriptiv, dauert aber ewig zu lesen und führt beim Nachschreiben garantiert zu Vertippern.

Man kann zwar mit Konventionen arbeiten – allerdings denke ich, daß man mit Konventionen, sinnvoller Dokumentation und gesundem Menschenverstand dafür sorgen kann, daß Variablen auch ohne ungarische Notation nachvollziehbar sind. Eine erklärende Kommentarzeile kann mehr über das aussagen, was eine Varaible bedeuten soll, als ein 20 Byte langer String.