Welche Art Notation wendet ihr an?

[Jim Carrey]

Mich würde mal interessieren, welche Art Notation ihr anwendet und besonders auch warum.

Ich wende eine Art ungarische Notation an, aber nicht wirklich:

Delphi-Quellcode:

// Normale Variablen
var
 sString: String;
 iInteger: Integer;
 dDouble: Double;
 fFloat: Float;
 pPointer: Pointer;

// Properties
FiMeinProperty: Integer;
property iMeinProperty: Integer read FiMeinProperty write FiMeinProperty;

// Parameter in Funktions- und Prozedurenköpfen (erster Buchstabe der Funktion/Prozedur immer klein und ein "a" vor den Parametern)
procedure test(aString: String);

// Klassen und Typen
type
 TMeineKlasse = class
 private
  //
 public
  //
 end;

type
 TMeinType = ....

[Der schöne Günther]

Im Leben nicht. Warum? Das ist doch völlig redundant. Grade in Delphi mit seiner (fast schon übertriebenen Typsicherheit) hat man dadurch doch rein gar nichts gewonnen.

Siehe auch:
https://de.wikipedia.org/wiki/Ungari...otation#Kritik

[jaenicke]

Solche Präfixe braucht man bei Delphi nicht, da die Variablen ohnehin feste Typen haben. Dazu kommt, dass der Variablenname selbst schon einen Hinweis geben sollte was das für ein Typ ist.
Dass zum Beispiel ItemName kein Integer ist, ist ohnehin klar.

Deshalb macht man sich dadurch nur unnötig Arbeit. Wenn der Quelltext ordentlich strukturiert ist und die Bezeichner ordentlich benannt, braucht man diese Information nicht.

Wo ich tatsächlich Präfixe setze, ist bei visuellen Komponenten. Das hat den Grund, dass ich den konkreten Namen einer Komponente natürlich nicht immer im Kopf habe. Ich will aber auch nicht jedesmal nachschauen müssen. Deshalb heißen Labels z.B. lblXYZ. Ich brauche also nur lbl eingeben um alle Labels vorgeschlagen zu bekommen. In der dann kleineren Liste finde ich in der Regel auch sofort was ich suche.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1351360)

Wo ich tatsächlich Präfixe setze, ist bei visuellen Komponenten. Das hat den Grund, dass ich den konkreten Namen einer Komponente natürlich nicht immer im Kopf habe. Ich will aber auch nicht jedesmal nachschauen müssen. Deshalb heißen Labels z.B. lblXYZ. Ich brauche also nur lbl eingeben um alle Labels vorgeschlagen zu bekommen. In der dann kleineren Liste finde ich in der Regel auch sofort was ich suche.

Insbesondere kann man das zu diesem TLabel gehörende TEdit dann z.B. auch sinnvoll edtXYZ nennen.

[Der schöne Günther]

Da stimme ich zu - Bei visuellen Komponenten habe ich das auch drin.

Aber warum als Prefix, und nicht als Suffix? Wenn es z.B.

Delphi-Quellcode:

userInputEdit

und

Delphi-Quellcode:

userInputSubmitButton

heißt habe ich direkt die Teile die zum "UserInput" gehören. Stände es nicht am Anfang müsste ich danach suchen.

[SProske]

Ich weiß nicht, wie man das nennt, aber:
- grundsätzlich CamelCase
- Interfaces mit führendem I, Klassen mit führendem T
- Klassenvariablen mit führendem F (die Property dann entsprechend ohne dieses)
- Visuelle Komponenten mit führendem Komponententyp (voll ausgeschrieben, also EditName, nicht EdtName), außer VirtualStringTree, bei dem nur VSTIrgendwas
- Zählvariablen I, J, K usw.
- sonst keine Prä-/Suffixe und hoffentlich sprechende Namen

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1351363)

Aber warum als Prefix, und nicht als Suffix? Wenn es z.B.

Delphi-Quellcode:

userInputEdit

und

Delphi-Quellcode:

userInputSubmitButton

heißt habe ich direkt die Teile die zum "UserInput" gehören. Stände es nicht am Anfang müsste ich danach suchen.

Beide Varianten haben sicher ihre Vor- und Nachteile. Damit bleibt es wohl Geschmackssache. Ich halte es in diesem Fall wie Sebastian, unter anderem auch, weil ich einen Analyzer habe, der die Einhaltung dieser Regel überprüft.

[sh17]

Ich bevorzuge _ vor Paramter-Bezeichnungen

also

Code:

procedure Do(_Val : Integer);
...

function Do(const _Val : String; out _Result : Integer) : Boolean;
...

[Aviator]

Zitat:

Zitat von Uwe Raabe (Beitrag 1351365)

Zitat:

Zitat von Der schöne Günther (Beitrag 1351363)

Aber warum als Prefix, und nicht als Suffix? Wenn es z.B.

Delphi-Quellcode:

userInputEdit

und

Delphi-Quellcode:

userInputSubmitButton

heißt habe ich direkt die Teile die zum "UserInput" gehören. Stände es nicht am Anfang müsste ich danach suchen.

Beide Varianten haben sicher ihre Vor- und Nachteile. Damit bleibt es wohl Geschmackssache. Ich halte es in diesem Fall wie Sebastian, unter anderem auch, weil ich einen Analyzer habe, der die Einhaltung dieser Regel überprüft.

Ich bevorzuge den Präfix. Wenn man kein CnPack benutzt, dann findet auch die Delphi Integrierte Eingabehilfe direkt die Komponenten. In Verbindung mit CnPack würde auch ein Suffix funktionieren weil CnPack alle Teile des Namens betrachtet.

Früher hatte ich Suffixe verwendet, bin aber schon vor Jahren zu dem Schluss gekommen, dass Präfixe (zumindest für mich) wesentlich besser sind.

[sahimba]

Zitat:

Zitat von sh17 (Beitrag 1351366)

Ich bevorzuge _ vor Paramter-Bezeichnungen

Das ist nicht schön vong Ästhetik her.

Ich verwende ein A. AValue, AName...
Lokale Variablen erhalten ein führendes L um sie von möglicherweise gleichnamigen Properties uzu unterschieden.
Ansonsten, das übliche: Klassen, Enums, Records ein T, Interfaces ein I, Felder ein F. Konstanten ein führendes C.

[Rollo62]

Zitat:

Wo ich tatsächlich Präfixe setze, ist bei visuellen Komponenten.

Das ist aber inkonsequent.
Da gilt dann doch das Gleiche wie bei iCount, sFactor, strId ...

Warum ist das verpönt, das andere aber nicht ?

Rollo

[Jim Carrey]

Zitat:

Warum ist das verpönt, das andere aber nicht ?

Warum sind Präfixe vor Variablennamen verpöhnt aber vor Typen, Enums usw nicht?
Streng genommen ist das T vor Klassen und das F for Properties auch redundant.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1351401)

Das ist aber inkonsequent.
Da gilt dann doch das Gleiche wie bei iCount, sFactor, strId ...

Warum ist das verpönt, das andere aber nicht ?

Weil man viel öfter und gezielter nach einem

Delphi-Quellcode:

TLabel

,

Delphi-Quellcode:

TEdit

oder einer

Delphi-Quellcode:

TCheckBox

sucht als nach einem

Delphi-Quellcode:

Integer

,

Delphi-Quellcode:

string

oder sonstigen Typen. Mit den Control-Präfixen wird weniger der Typ sonder eher die Bedeutung dargestellt.

Ich verwende das Präfix edt z.B. auch für Controls, die kein echtes TEdit sind, sondern wegen des Datentyps mit einem speziell dafür geeigneten Control dargestellt werden (z.B. TDbEdit oder TDateTimePicker). So kann ich das Control auch mal ohne großes Tamtam austauschen. Das Diff beim CheckIn wird damit auch viel übersichtlicher.

Das ist eben der Unterschied zwischen dogmatisch und pragmatisch.

[Rollo62]

Ist halt doch am Ende Geschmachssache.

So ziehe ich meine System eben seit Assember, C/C++ bis heute durch, und Alles
ist prima für mich lesbar und verständlich in einem ähnlichem Kontext.
Auch wenns vielleicht etwas "dogmatisch" erscheint, ich finde Hauptsache man findet die Bedeutung schneller, das kann halt jeder für sich selbst entscheiden.

Leider gibt es bei mehreren Programmierern oder Libraries dann doch wieder verschiedene
Schnittstellen, aber die Probleme damit halten sich ja Alle in Grenzen.

Wenn wir endlich soweit sind das alle Syntax gleich aussieht, dann werden Programme auch von Computern geschrieben, und die Programmierer müssen sich das sowieso nicht mehr ansehen :stupid:

Zu den "edtXyz" Kürzeln finde ich, dann lasse ich es auch einfach als EditXyz stehen,
denn da hilft mit AutoCompletion doch sowieso erheblich.
Und die Bezeichner lassen sich später noch super refaktorieren.

Rollo

[mkinzler]

Solange alle die am Code arbeiten die Notation kennen bzw. die selbe verwenden ist doch alles ok.

[bra]

Zitat:

Zitat von Rollo62 (Beitrag 1351406)

Zu den "edtXyz" Kürzeln finde ich, dann lasse ich es auch einfach als EditXyz stehen,
denn da hilft mit AutoCompletion doch sowieso erheblich.
Und die Bezeichner lassen sich später noch super refaktorieren.

Mag bei einem Label oder einem Edit noch möglich sein, aber ein TabcSchiessMichTotDateTimeEditNameXY ist dann doch etwas unhandlich ;)

Ich finde die Notation für lokale Variablen eher überflüssig, weil i.d.R. in einer Funktion nicht zu viele Variablen verwendet werden (sollten) und man da den Überblick relativ einfach behalten kann, vor allem wenn man denen sinnvolle Namen gibt. Wenn man irgendwann bei 20 oder mehr Variablen ist, sollte man sich vielleicht überlegen, die Funktionen aufzuteilen.

[sh17]

Zitat:

Zitat von sahimba (Beitrag 1351394)

Zitat:

Zitat von sh17 (Beitrag 1351366)

Ich bevorzuge _ vor Paramter-Bezeichnungen

Das ist nicht schön vong Ästhetik her.

Mag sein.

Noch ein Beispiel, wo der Zusammenhang zwischen Property und Parameter bei Vergleichen oder Zuweisungen klar wird (für mich zumindest)
Natürlich könnte ich jetzt den Parameter NewVal nennen, möchte ich aber nicht.

Code:

procedure TFoo.Do(_Val : Integer);
begin
  if not (Val = _Val) then
    Val := _Val;
end;

[Mavarik]

Zitat:

Zitat von Jim Carrey (Beitrag 1351403)

Streng genommen ist das T vor Klassen und das F for Properties auch redundant.

Delphi-Quellcode:

Var
  Data  : TDaten; // Klasse
  Data2 : Daten;  // Record früher habe ich DatenRec; geschrieben
  IData : ICanHandleDaten;// Interface

und

Delphi-Quellcode:

FData := 20; // Klassen Var
LData := 20; // Local Var
AData := 20; // Parameter Var
IData.Wert := 20;  // Interface Var
_Result := 20; // Result ist ein OUT Parameter und nicht das Funktionesergebniss

[einbeliebigername]

Hallo,

ich muss auch mal mein Unqualifiziertes zum Thema geben. Erst mal kann man über dieses Thema, wie über ähnliche (Formatierung), diskutieren und dabei viele Biere (oder ähnliches) die Kehle runterkippen ohne zu einem wirklichen Ende zu kommen.

Diese Präfixe i für Integer, s für String kommen meiner Meinung nach aus der C-Welt (jedenfalls ist es mir dort das erste Mal aufgefallen). Die gesamte WinApi ist ja damit gespickt.

Das folgende ist meine Erklärung wie und vor allem wieso ich es bei dem Thema so halte.

Eigentlich braucht man keine Präfixe/Postfixe. Eigentlich.

Für mich ist wichtig, dass der Code leicht zu lesen und zu verstehen ist. Deshalb verwende ich möglichst aussagekräftige Bezeichner. Bei mir ist es so, dass mit meinem Alter scheinbar die Bezeichner immer länger werden. Sie bestehen meist aus mehreren Wörtern. Diese müssen wegen der Leserlichkeit erkennbar (nicht nur für mich auch für andere) voneinander getrennt sein. Keiner will sowas lesen müssen:

Delphi-Quellcode:

dasisteinwirklichlangerbezeichnerweilderverfassermalwiderkeinendebeimdichtenfindenkonnte

Die Trennung darf dabei die Bezeichner nicht noch länger machen. Damit gibt es nicht mehr so viele Möglichkeiten dies zu schaffen. Auch stehen in Delphi sehr wenige Trennzeichen zur Verfügung. Und ich hasse den Unterstrich wie die Pest. Ab einer gewissen Anzahl an Unterstrichen hintereinander wie in C/C++, kann man schlecht erkennen wie viele es sind (z.B.___________________).

@sh17: Und fällt dir was auf:
function Do(const _Val : String; out _Result : Integer) : Boolean;

Die Unterstreichung von Text ist eine verwendbare Darstellungsform, welche man auch mit jedem Bezeichner verwenden können soll. Ich glaube den Unterstrich hat der Teufel in den Zeichensatz gedrückt.

Ich trenne die Wörter in den Bezeichnern mit Hilfe der Großkleinschreibung. Und ich hasse Programmiersprachen/Betriebssysteme welche es nicht schaffen zu erkennen, dass index/index.html und Index/Index.html ein und das Selbe ist. Denn ich möchte am Telefon, beim Stammtisch noch über das, was ich am Rechner mache, sprechen können. Und es tut mir leid, ich bin zu blöd und kann Großkleinschreibung weder aussprechen noch hören.

Bei der Großkleinschreibung verfahre ich mit gebräuchlichen Abkürzungen wie ABS für Antiblockiersystem als währen diese Wörter. Also

Delphi-Quellcode:

ActivateAbs

.

Nun kommt es vor, dass man beim Programmieren mehrere Bezeichner für ein und das Selbe in einem Gültigkeitsbereich benötigt. Wie zum Beispiel bei einer Klasse welche ein Property

Delphi-Quellcode:

Value

hat und man dazu noch ein privates Feld benötigt. Einen Bezeichner von Beiden muss man erweitern, um diese auseinanderhalten zu können. Bei der Erweiterung gilt auch, sie darf den Bezeichner nicht viel länger machen. Auch muss sie nach einem, auch für andere erkennbaren, Schema richten, welches auch gut an anderen Stellen funktioniert und möglichst viele Konflikte löst. Auch muss sich die Erweiterung deutlich erkennbar von dem wichtigen Teil des Bezeichners abheben.

Zitat:

Zitat von Der schöne Günther (Beitrag 1351363)

Aber warum als Prefix, und nicht als Suffix? Wenn es z.B.

Delphi-Quellcode:

userInputEdit

und

Delphi-Quellcode:

userInputSubmitButton

heißt habe ich direkt die Teile die zum "UserInput" gehören. Stände es nicht am Anfang müsste ich danach suchen.

Leider hast du zu wenige Beispiele genannt, als das man daraus wirklich dein Schema erkennen kann. Zwar hast du das hier bereits verraten. Aber ich versuche das mal an einem einzelnen Bezeichner bewusst Falsch zu verstehen (und reite jetzt bestimmt auf einem kleinen Fehler rum). Ich will das aber mal zum Besten geben, in der Hoffnung, dass daraus noch eine hübsche friedliche Diskussion entsteht. Also wenn ich bei dir darauf kommen würde, dass du ein Postfix anhängst, würde ich bei

Delphi-Quellcode:

userInputEdit

verstehen, dass es ein Eingabefeld user gibt was vom Typ TInputEdit ist. Na, vieleicht gibt es ja auch ein TOutputEdit. Aber was vom user soll der Benutzer da eingeben? Den Kopf, den Arm, ...? Man soll ja Menschen leben lassen! Jeder hat seine eigenen Vorstellungen und Ansichten!

Wieso aber jetzt nicht als Posfix? Wie soll man erkennbar getrennt an Bezeichner wie Value, ChoiceA, ChoiceB was anhängen, wenn man das Teufelszeichen nicht verwenden will? Deshalb als Prefix. Der Prefix besteht bei mir in der Regel nur aus Kleinbuchstaben. Orientiert habe ich mich da an den Enums zu Delphi 5-7 Zeiten. Die hatten damals ja auch so Prefixe davor, damit man gleichbenannte Werte unterschiedlicher Enums auseinander halten konnte. Mit dem Ersten Großbuchstaben fängt der wichtige Teil des Bezeichners an.

@Der schöne Günther: Das Problem mit dem Suchen bei der Verwendung von Prefixen ist tatsächliche eine Schwäche von Delphi, die Emba sicherlich einfach besser machen könnte. CnPack macht das so wie Visual Studio und listet auch Treffer auf, wo das gesuchte mittendrin steht. Ich weiß das hat auch wieder seine Vor- und Nachteile. Da muss man sich entscheiden, was einem wichtiger ist.

Und dieses Prefix-Schema verwende ich überall wo ich zu ein und demselben Ding verschiedene Bezeichner brauche. Während ich das jetzt hier zum Besten gegeben habe, fiel die Entscheidung das auch noch weiter auszubauen.

Delphi-Quellcode:

type
  TMyClass= class(TEdit)
  strict private
    fValue: Integer

    function gValue: Double;
    procedure sValue(const aValue: Double);
  published
    property Value: Double read gValue wirte sValue;
  end;

procedure TMyClass.sValue(const aValue: Double);
var
  vValue: Integer;
begin
  vValue:= Round(aValue);
  if fValue<> vValue then
  begin
    fValue:= vValue;
    ...
  end;
end;

Ja und dabei habe ich hier und da noch einige Konflikte. Es müsste eigentlich

Delphi-Quellcode:

tMyClass

sein. Dann aber auch

Delphi-Quellcode:

tEdit

. Das Framework von Delphi gibt einem doch schon eine gewisse Vorgabe, von der man hier und da nur schwer abweichen kann. Denn wirklich richtig fände ich

Delphi-Quellcode:

cMyClass

und

Delphi-Quellcode:

cEdit

.

Ja wieso jetzt nicht das t für Klassen? Ich habe an einer Stelle für ein und das Selbe (meine schicken Zeithunde) ein Record und eine Klasse. Das Record um mittels überladener Operatoren leicht verständlich zu Rechnen und die Kasse um das einfach ohne Verrenkung speichern zu können (ja auch in der DFM).

Ob nur Prefix, Postfix oder gar nicht hat alles seine Vor- und Nachteile. Ich weiß nicht ob wir Entwickler da jemals einen Konsens schaffen. Wenn nicht, würde ich mir wünschen, dass man trotz Verwendung unterschiedlichster Frameworks und Programmiersprachen dann sein eigenes Ding diesbezüglich gänzlich durchziehen kann.

einbeliebigername.

[Rollo62]

Zitat:

aber ein TabcSchiessMichTotDateTimeEditNameXY ist dann doch etwas unhandlich

Das ist richtig, aber auch da gibt es trotzdem immer noch Gegenargumente:

"TabcSchiessMichTotDateTimeEditNameXY" läst sich fantastisch (unique) textuell in allen Dateien suchen, hingegen
"dat" wird bei der Text-Suche an drei Trillionen Stelen auftauchen.

Es kommt halt immer auf die Sichtweise an, was ich gerade erledigen möchte.
Ein allgemeines Rezept bleibt wohl schwierig, deswegen lasse ich jedem gerne sein Lieblingsformat, denn
vielleicht liege ich ja auch mal falsch mit meinen Ansichten :stupid:

Nach dem Motto: Alles geht ...

Rollo

[Der schöne Günther]

Zitat:

Zitat von einbeliebigername (Beitrag 1351490)

Also wenn ich bei dir darauf kommen würde, dass du ein Postfix anhängst, würde ich bei userInputEdit verstehen, dass es ein Eingabefeld user gibt was vom Typ TInputEdit ist. Na, vieleicht gibt es ja auch ein TOutputEdit. Aber was vom user soll der Benutzer da eingeben? Den Kopf, den Arm, ...? Man soll ja Menschen leben lassen! Jeder hat seine eigenen Vorstellungen und Ansichten!

Wie Uwe schon gesagt hat ist es im Endeffekt relativ egal ob es nun ein

Delphi-Quellcode:

TEdit

, ein

Delphi-Quellcode:

TLabeledEdit

, ein

Delphi-Quellcode:

TSpinEdit

oder etwas anderes ist. Es ist ein Edit-Ding für den User-Input.

Ich glaube du nimmst das Beispiel auch zu sehr auseinander. Entweder hätte man eine noch sehr überschaubare Anzahl (z.B. drei) wie

Delphi-Quellcode:

firstNameEdit

,

Delphi-Quellcode:

secondNameEdit

und

Delphi-Quellcode:

birthdayDatepicker

, oder man fasst die einzelnen Komponenten nicht mehr an denn man hat einen Frame der das kapselt:

Delphi-Quellcode:

TCredentials = record
  firstName: String;
  lastName: String;
  birthDay: TDate;
end;
TCredentialsFrame = class(TFrame)
[...]
  public property Credentials: TCredentials read getCredentials write setCredentials;
end;

Aber wir entfernen uns glaube ich immer weiter von der eigentlichen Frage der Ungarischen Notation.

[einbeliebigername]

Hallo,

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Wie Uwe schon gesagt hat ist es im Endeffekt relativ egal ob es nun ein

Delphi-Quellcode:

TEdit

, ein

Delphi-Quellcode:

TLabeledEdit

, ein

Delphi-Quellcode:

TSpinEdit

oder etwas anderes ist.

Das sehe ich ja auch so. Ich verwende für die verschiedenen Edit-Komponenten mittlerweile auch dasselbe Prefix.

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Ich glaube du nimmst das Beispiel auch zu sehr auseinander.

Nein ich hatte doch schon geschrieben, dass ich das bewusst übertrieben falsch Interpretiert habe. Ich habe dich nur als Beispiel genommen um was auszudrücken.

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Entweder hätte man eine noch sehr überschaubare Anzahl (z.B. drei) wie

Delphi-Quellcode:

firstNameEdit

,

Delphi-Quellcode:

secondNameEdit

und

Delphi-Quellcode:

birthdayDatepicker

, oder man fasst die einzelnen Komponenten nicht mehr an denn man hat einen Frame der das kapselt:

Nein das ist es nicht was ich meine. Es ging und geht mir nur um die Art und Weise wie du deine Bezeichner schreibst. Ich habe jetzt verstanden das du diese so schreibst:

Delphi-Quellcode:

firstNameEdit

und

Delphi-Quellcode:

firstNameLabel

. Dabei ist

Delphi-Quellcode:

firstName

der wichtige Teil des Bezeichners und

Delphi-Quellcode:

Edit

bzw.

Delphi-Quellcode:

Label

bei dir das Anhängsel. Habe ich das so richtig erfasst? In meinen XE8 gibt es leider keine TDatepicker-Komponenten sondern nur eine TDateTimePicker, deshalb nehme ich jetzt zu Erklärung diese. Dann würde ich der Logik wegen bei deinem

Delphi-Quellcode:

birthday

erwarten, dass die zugehörigen Komponenten

Delphi-Quellcode:

birthdayDateTimePicker

und

Delphi-Quellcode:

birthdayLabel

heißen. Und wenn es ein

Delphi-Quellcode:

firstWorkDay

gäbe, dann

Delphi-Quellcode:

firstWorkDayDateTimePicker

und

Delphi-Quellcode:

firstWorkDayLabel

. Richtig?

Mir würde da die klar erkennbare Trennung zwischen dem wichtigen aussagekräftigen Teil und dem eigentlich nicht benötigten Anhängsel fehlen.

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Delphi-Quellcode:

TCredentials = record
  firstName: String;
  lastName: String;
  birthDay: TDate;
end;

Du schreibst wirklich den Anfangsbuchstaben der Bezeichner klein oder gibt es da bei dir eine Regel?

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Delphi-Quellcode:

TCredentialsFrame = class(TFrame)
[...]
  public property Credentials: TCredentials read getCredentials write setCredentials;
end;

Weil das Property hast du mit groß begonnen. Aber Setter und Getter wieder klein. Und die Anhängsel an Setter/Getter stehen vorn. Oder schreibst du deine Bezeichner dem Klang nach?

Zitat:

Zitat von Der schöne Günther (Beitrag 1351568)

Aber wir entfernen uns glaube ich immer weiter von der eigentlichen Frage der Ungarischen Notation.

Ich hoffe nicht. Ich bin der Meinung, dass es dem TE genau um die Art und Weise geht, wie man seine Bezeichner schreibt.

Ich hätte nicht so faul sein sollen und mir mal den verlinkten Wiki-Artikel durchlesen. Gänzlich habe ich das jetzt auch nicht gemacht. Aber bei weiter Auslegung gehe ich doch nach der Ungarischen Notation vor, bloß das ich keine Typinformationen im Prefix und die Sichtbarkeit mit der Art in einem Teil zusammengefasst habe und ich immer einen aussagekräftigen Namen ans Prefix hänge. Nur, wie in dem Artikel erwähnt, mit den reinen Prefixen, wenn auch nur zum Teil, zu programmieren, würde bei mir zum Wahnsinn führen.

@Der schöne Günther: Nur weil es mich interessiert. Wärst du so freundlich mal mein

Delphi-Quellcode:

TMyClass

-Beispiel so umzuformatieren, dass man erkennt wie du da deine Bezeichner schreiben würdest.

einbeliebigername.

[Uwe Raabe]

Zu dem Thema gibt es einen etwas länglichen, aber interessanten Artikel von Joel Spolski: Making Wrong Code Look Wrong.
Für den eiligen Leser empfiehlt sich der direkte Sprung zu dem Abschnitt mit der Überschrift I’m Hungary. Die Kernaussage dort ist in etwa diese (zur Info: Charles Simonyi ist der Erfinder der Hungarian Notation):

Zitat:

In Simonyi’s version of Hungarian notation, every variable was prefixed with a lower case tag that indicated the kind of thing that the variable contained.
For example, if the variable name is rwCol, rw is the prefix.
I’m using the word kind on purpose, there, because Simonyi mistakenly used the word type in his paper, and generations of programmers misunderstood what he meant.

Zitat:

In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.” Both ints. Not interchangeable.