Präfix oder Suffix - Wie haltet Ihr es mit der Namensgebung?

[mm1256]

Zitat von Rollo62:

Das wäre bei mir:

Code:

KundenFrm.pas
KundenDm.pas
KundenData.pas

Und schon habe ich lesbaeren Code, der sich auch noch sehr gut mit Codevervollständigung verträgt.
Das meinte ich mit "Klassenähnlich".

In der ".dpr" sortiere ich die Uses-Liste generell nach Dateinamen und da hab ich die Formulare, Dialoge und Datenmodule gerne schön beisammen. Das ist mir lieber als bei deiner Variante alle "Kunden-Units" beisammen zu haben.

Aber, das soll jetzt keine Kritik oder Abwertung sein. Wie schon mehrfach angemerkt, alles Geschmacksache. Macht jeder so wie er es gewohnt ist, und für richtig hält.

Zitat von Rollo62:

Manchmal muss es Q&D gehen.

Stimmt. Ich habe aber die Erfahrung gemacht, dass sich Q&D niemals lohnt, denn irgendwann geht einem dieser Q&D-Code auf den Geist und dann ändert man doch ab, und dabei passieren dann gerne Flüchtigkeitsfehler. Zumindest geht (bzw. ging) es mir früher so, und darum hasse ich Q&D wie die Pest. Hat unter'm Strich noch nie was gebracht. Außer im Nachhinein Mehrarbeit, Ärger und Stress.

[Rollo62]

Hallo mm1256,

ich denke das ist alles eine Frage der Abwägung.
Weder das funktionale Konzept noch das Klassenkonzept ist richtig wenn man es übertreibt.
Die Mischung macht es eben.

Nimm z.B. eine StateMachine.
Die mache ich sehr oft mit einfachen

Code:

 case xx of 
  1:;
  2:;
  3:;
  end

wenn es für mich noch überschaubar bleibt.
Das ist für mich lesbar genug, natürlich ist das total verpönt ...

Ich könnte natürlich bei jeder Kleinigkeit einen neue Klasse bauen und das mit Methodenpointern lösen, etc. etc.

Ich gebe dir Recht das diese "immer Klassen" Logik vielleicht richtig ist bei
- sehr grossen Projekten
- wenn viele Entwickler beteiligt sind
- wenn das z.B. in Packages benutzt wird die vertrieben werden sollen
etc.

Aber weil ich meistens meinen Code alleine pflegen muss, und weil die Module sehr selten irgendwo weiterverwendet werden können
muss ich halt abschätzen was nützt und was nicht.

Deshalb habe ich einen Mittelweg, der Klassenaufteilung per Namen schon vorzeichnet, und dann bei Bedarf schnell ausgegliedert
werden kann, weil alle zusammenhängenden Teile schnell gefunden werden.

Mich stört schon z.B. die IDE Automatic das GetVariable, SetVariable angelegt wird, und nicht VariableGet, VariableSet.
Letzteres würde die beiden Methoden untereinander platzieren, ersteres verteilt es wild im Unit.

Natürlich habt ihr nur Units die alle auf einen Bildschirm passen, aber soweit bin ich vielleicht noch nicht

Rollo

[Sir Rufo]

Die Bezeichnung ist aber korrekt. Ein Befehl ist immer ein Imperativ.

Kommando: SetValue
und löst bei Erfolg das
Ereignis: ValueChanged
aus.

[Rollo62]

Ich sage ja das es gewöhnungsbedürftig ist, aber es listet mir bei autovervollständigung alles schön zusammen auf,
was sehr stark hilft die Übersicht zu behalten.

Für gutes englisch bekomme ich dann wohl keinen Preis.

Zitat:

Kommando: SetValue
und löst bei Erfolg das
Ereignis: ValueChanged

Genau das ist ein gutes Beispiel was ich meine:

Code:

ValueSet
ValueGet
ValueChanged

Rollo

[idefix2]

Zitat:

weil die Module sehr selten irgendwo weiterverwendet werden können
muss ich halt abschätzen was nützt und was nicht.

Ob du da nicht Ursache und Wirkung verwechselst? Je kleiner und elementarer man die Prozeduren gestatet, desto wiederverwertbarer werden sie.
Wobei man es natürlich auch übertreiben kann.

[p80286]

Zitat von idefix2:

Zitat:

weil die Module sehr selten irgendwo weiterverwendet werden können
muss ich halt abschätzen was nützt und was nicht.

Ob du da nicht Ursache und Wirkung verwechselst? Je kleiner und elementarer man die Prozeduren gestatet, desto wiederverwertbarer werden sie.
Wobei man es natürlich auch übertreiben kann.

Ist vielleicht auch eine Frage der Sichtweise. Auf der einen Seite willst Du ein "EingangsdatumVerarbeiten" auf der anderen "KonvertUSdate2ISODate". Und die Grenze zwischen aufgabenbezogenen Prozeduren/Funktionen und allg. verwendbaren, ist manchmal sehr fließend.

Gruß
K-H

[Sherlock]

Ich mag mich ja irren, aber mein XE2 bietet mir bei der Codevervollständigung alle Bezeichner an, die die von mir getippte Zeichenfolge enthalten, nicht nur die, die damit beginnen. Wo also was steht ist dem Delphi vollkommen egal. Ist das bei den neueren Delphis geändert worden?

Sherlock

[Sir Rufo]

Zitat von Rollo62:

Ich sage ja das es gewöhnungsbedürftig ist, aber es listet mir bei autovervollständigung alles schön zusammen auf,
was sehr stark hilft die Übersicht zu behalten.

Für gutes englisch bekomme ich dann wohl keinen Preis.

Zitat:

Kommando: SetValue
und löst bei Erfolg das
Ereignis: ValueChanged

Genau das ist ein gutes Beispiel was ich meine:

Code:

ValueSet
ValueGet
ValueChanged

Rollo

Für gutes Deutsch auch nicht.

Kommando:
SetzeWert
HoleWert
Ereignis:
WertGeändert

Und beim Programmieren will ich entweder einen Befehl ausführen (CreatePerson/CreateFoo/CreateBar) fange mit Create an und bekomme alles was ich erzeugen kann aufgelistet, oder ein Ereignis behandeln/auslösen (PersonCreated/PersonChanged/PersonDeleted). Dann ist aber auch der Kontext klar und ich fange mit dem Kontext Person an und bekomme alle Events zum Kontext.

[Mavarik]

Zitat von Sir Rufo:

Und beim Programmieren will ich entweder einen Befehl ausführen (CreatePerson/CreateFoo/CreateBar) fange mit Create an und bekomme alles was ich erzeugen kann aufgelistet, oder ein Ereignis behandeln/auslösen (PersonCreated/PersonChanged/PersonDeleted). Dann ist aber auch der Kontext klar und ich fange mit dem Kontext Person an und bekomme alle Events zum Kontext.

Ich versuche meine Variablen / Proceduren nicht mit Delphi Methodennamen zu mischen CreateKunde.

Lieber ein

Delphi-Quellcode:

Function ErzeugeKunde:TKunde;
begin
  Result := TKunde.Create;
  ....
end;

[Sir Rufo]

Zitat von Mavarik:

Ich versuche meine Variablen / Proceduren nicht mit Delphi Methodennamen zu mischen CreateKunde.

Lieber ein

Delphi-Quellcode:

Function ErzeugeKunde:TKunde;
begin
  Result := TKunde.Create;
  ....
end;

Nein, du schreibst es in deutsch und darum ist es per Definition schon mal anders. Dei Bedeutung ist aber gleich und der Name sowieso Schall und Rauch. Trotzdem nimmst du für ein Kommando auch den Imperativ

ErzeugeKunde
LöscheKunde

Was eben nicht nur vom Lesen her besser zu verstehen ist als KundeErzeuge oder KundeLösche.

Allerdings ist es völlig wurscht, ob das in deutsch, englisch oder Postmodern-Esperanto geschrieben wird. CreateCustomer oder ErzeugeKunde kann der Compiler sehr gut von TCustomer.Create /TKunde.Create unterscheiden. Macht dem also nichts.