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

[Dejan Vu]

Wieso definierst Du dir nicht einfach eine Message ('WM_MyMessage') und sendest die per Broadcast an alle Fenster. Deine eigenen Fenster antworten dann auf diese message mit ihrem Handle und einer ID. Daran kannst Du dann im Sender genau den Empfänger ermitteln, den Du willst. Und zwar *ohne* die Caption zu verwenden.

Ich finde das sauberer als mit FindWindow. Aber wenn sich bei Dir die Caption eh nie ändert (oder das Fenster gar unsichtbar ist und nur als Kommunikationsplattform dient), dann ist das mindestens genauso gut.

Zitat:

Zitat von Captnemo (Beitrag 1310497)

Da ich mir das CN-Pack installiert habe, werden bei Komponenten auf der Form diese gleich automatisch umbenannt.

Das kann GExperts auch.

[Rollo62]

Nur mal ein Beispiel, damit ihr nicht ständig auf der Wolle-Klasse besteht.

Code:

Ein FormName beginnt immer mit dem Präfix "Frm", z.B. "FrmKunden". Ist es ein Hauptformular heißt die Unit "Main_Kunden.pas", ist es ein modaler Dialog entsprechend "Dlg_Kunden.pas". Bei DB-Anwendungen heißt die entsprechende Datenmodul-Unit "Dat_Kunden.pas". Die Interface-Procedure zum Anzeigen eines Formularess (ich erzeuge generell alle Formulare zur ....

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

Ausserdem habe ich nicht immer die Zeit für jede mögliche Sub-Klasse diese auch auszugliedern.
Manchmal muss es Q&D gehen.
Über diese Schreibweise ist der Zusammenhang dann schonmal vorgemerkt, und ich kann dann später leicht eine Klasse draus machen.

Rollo

[Dejan Vu]

Leider ist das primäre Programmiermodel von Delphi (TDataModule, Komponenten) nur bedingt geeignet, bei komplexeren Projekten ein objektorientiertes Design durchzuziehen. Da muss man dann eben zu solchen Nomenklaturkrücken greifen.

Ähnlich ist das bei SQL, das auch keine Namespaces und Klassen vorsieht: Hier verwendet man Schemaspaces, um ein wenig Ordnung in das Chaos zu bringen. Das entspricht in etwa dem Bestreben, den Namen der Entität ("Kunde") als Präfix für die unterschiedlichen Objekte zu verwenden.

Leider ist das -zumindest bei SQL- nur bis zu einem gewissen Grad möglich, das man imho keine echten Namespacehierarchien("Foo.Bar.Blub.Bla") aufbauen kann. In Delphi geht das, zumindest bei den Unit-Namen(:gruebel:)

Aber immerhin: Ordnung ist das halbe Leben.

[mm1256]

Zitat:

Zitat von Rollo62 (Beitrag 1310642)

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:

Zitat von Rollo62 (Beitrag 1310642)

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:

Zitat von idefix2 (Beitrag 1310896)

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:

Zitat von Rollo62 (Beitrag 1310671)

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:

Zitat von Sir Rufo (Beitrag 1310937)

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:

Zitat von Mavarik (Beitrag 1310942)

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.

Delphi-Quellcode:

CreateCustomer

oder

Delphi-Quellcode:

ErzeugeKunde

kann der Compiler sehr gut von

Delphi-Quellcode:

TCustomer.Create

/

Delphi-Quellcode:

TKunde.Create

unterscheiden. Macht dem also nichts.

[bernau]

Zitat:

Zitat von Sir Rufo (Beitrag 1310937)

Für gutes Deutsch auch nicht.

Kommando:
SetzeWert
HoleWert
Ereignis:
WertGeändert

Ähm? was ist an

• WertSetzen
• WertHolen
• WertErhoehen
• WertErzeugen

ein schlechtes Deutsch?

Ist doch viel besser, wenn ich mit dem Bezeichner (z.B. Kunde) anfange, denn ich will ja erst einmal etwas mit dem "Kunden" machen. Mir wird dann zum Kunden aufgelistet, was ich mit dem Kunden machen kann. Egal ob es Events oder Befehle sind.

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1310960)

Delphi-Quellcode:

CreateCustomer

oder

Delphi-Quellcode:

ErzeugeKunde

kann der Compiler sehr gut von

Delphi-Quellcode:

TCustomer.Create

/

Delphi-Quellcode:

TKunde.Create

unterscheiden.

Ach Echt? Warum mache ich mir dann die Mühe? :stupid:
Aber ich habe doch eine deutsche IDE... :cyclops:

8-)

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1310966)

Ähm? was ist an

• WertSetzen
• WertHolen
• WertErhoehen
• WertErzeugen

ein schlechtes Deutsch?

Ist doch viel besser, wenn ich mit dem Bezeichner (z.B. Kunde) anfange, denn ich will ja erst einmal etwas mit dem "Kunden" machen. Mir wird dann zum Kunden aufgelistet, was ich mit dem Kunden machen kann. Egal ob es Events oder Befehle sind.

Wenn die so einzeln da stehen, dann sieht es ja noch gut aus, aber jetzt packen wir mal die Events dazu:

• WertErhoehen
• WertErhoeht
• WertErzeugen
• WertErzeugt
• WertGesetzt
• WertHolen
• WertGeholt
• WertSetzen

und das vergleicht man jetzt mit dieser Liste

• ErhoeheWert
• ErzeugeWert
• HoleWert
• SetzeWert
• WertErhoeht
• WertErzeugt
• WertGesetzt
• WertGeholt

Ich kann mir nicht helfen, aber ich erkenne nun sofort, was ein Kommando und was ein Event ist ohne mir dort irgendetwas genauer anschauen zu müssen.

[Dejan Vu]

Leute, das ist doch Wurscht. Man kann sowohl die 'aktive' ('MachBierAuf') oder die passive ('BierAufmachen') verwenden. Wichtig ist, das man es stringent durchzieht, also nicht aktiv und passiv mischen. So wie Bier und Eiswürfel. Wie komm ich jetzt darauf?

Wenn man OOP verwendet, wird das sowieso zweitranging. Da heißen die Methoden dann 'Create', 'Load', 'Store' usw. und werden auf einen 'Customer', 'Kunden' etc. angewendet.

Übrigens: Wer Entitäts- und Aktionsnamen in einem Namen hat ('ErzeugeKunde' oder 'KundeErzeugen'), der könnte sich mal mit OOP beschäftigen. :stupid: Ist gar nicht so schwer. :mrgreen:

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1311004)

Übrigens: Wer Entitäts- und Aktionsnamen in einem Namen hat ('ErzeugeKunde' oder 'KundeErzeugen'), der könnte sich mal mit OOP beschäftigen. :stupid: Ist gar nicht so schwer. :mrgreen:

Oder er hat sich eingehender mit OOP beschäftigt
http://www.thewebhatesme.com/entwick...–-cqrs-teil-2/

Zitat:

Command
Ein Command ist ein Befehl, der eine Statusänderung durchführen soll. Er ist immer im Imperativ benannt: CreateCustomer, AddContactPerson, LockCustomer.

[Rollo62]

Sir Rufo,

schau dir einmal eine solche Namensvergabe in der CodeCompletion an und du wirst anfangen es zu lieben :-)

Sprache hin oder her ...

Rolf

[Sir Rufo]

@Rollo62

Da ich gerade dieses CQRS umsetze liebe ich genau den von mir vorgeschlagenen Ansatz ;)

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1311012)

Oder er hat sich eingehender mit OOP beschäftigt

:thumb: Von Feldnamen/Propertynamen war hier jetzt aber eigentlich nicht so die Rede, zumindest habe ich das nicht so verstanden (Event vielleicht).