Welche Art Notation wendet ihr an?

[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