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

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()

Aber immerhin: Ordnung ist das halbe Leben.

[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