Welche Art Notation wendet ihr an?

[sahimba]

Zitat von sh17:

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.

[Mavarik]

Zitat von Jim Carrey:

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

[Uwe Raabe]

Zitat von Rollo62:

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 TLabel , TEdit oder einer TCheckBox sucht als nach einem Integer , 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

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 von Rollo62:

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 von sahimba:

Zitat von sh17:

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;