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

[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.