Code strukturieren! Wie macht man es richtig ..

[EWeiss]

Eine grundsätzliche frage
Wie strukturiert man seinen Quelltext richtig.

Ich stelle fest das ich immer wieder in den alten trott von VB verfalle deshalb mal
diese frage um sicher sein zu können es direkt von vornherein richtig zu machen.

Ich lese eine zeile von einer Textdatei ein und übergebe diese wie folgt
zCAPTIONFONTHEIGHT(StrToInt(ParseThis(sBF, ',', 1)), 1);

Delphi-Quellcode:

function TSkinConfig.zCAPTIONFONTHEIGHT(N, RW : Integer): Integer;
begin
   if RW <> 0 then
    WasN := N;

  Result := WasN;

end;

Delphi-Quellcode:

TSkinConfig = class
private
 //
public
  function zCAPTIONFONTHEIGHT(N, RW : Integer): Integer;
end;

Den wert von zCAPTIONFONTHEIGHT lese ich so zurück!
Dafür habe ich in meiner SkinEngine Class eine extra Variable angelegt ebenfalls Public
function SK_CAPTIONFONTHEIGHT: Integer; Die abfrage oder wenn ich den wert verändern will läuft wie folgt

Delphi-Quellcode:

function TSkinEngine.SK_CAPTIONFONTHEIGHT: Integer;
begin
   Result := SkinConfig.zCAPTIONFONTHEIGHT(0, 0);

end;

Wird ein neuer wert RW übergeben wird dieser in WasN gespeicher solange bis ein neuer übergeben wird..
Frage ich den wert ab wie angezeigt
SkinConfig.zCAPTIONFONTHEIGHT(0, 0); bekomme ich als resultat den zuletzt übergeben Wert zurück geliefert.
Also in diesen Fall, den der aus meiner TextDatei eingelesen wurde.
Grundsätzlich funktioniert das aber mein bedenken es ist einfach nicht optimiert.
Da zu viel unnötiger Code geschrieben wird.

zu dem Thema noch eine zusätzliche Frage..
Was kommt nun genau unter Privat, Public, Published ?
Meine Frage deshalb damit ich nicht unötig langen Code abfragen muss..
So wie diesen hier.
SkinConfig.zAEROCOLOR(SkinEngine.zColorARGB(SkinEngine.zGetTrackValue(SkinEngine.zGetMainItem(ID_TRACK_OPACITY)),RGB(Red, Green, Blue)), WRITE); Wie kann man sowas optimieren das man nicht immer SkinEngine davor schreiben muss.
Ich muss also immer zwischen SkinConfig und SkinEngine hin und her wandern und jedesmal den namen noch davor schreiben.
Wenn ich alles ohne Class mache kann ich aus jeder unit auf alle Funktionen zugreifen.
Denke aber das wäre auch nicht der richtige weg.

gruss Emil

[mirage228]

Zitat von EWeiss:

SkinConfig.zAEROCOLOR(SkinEngine.zColorARGB(SkinEngine.zGetTrackValue(SkinEngine.zGetMainItem(ID_TRACK_OPACITY)),RGB(Red, Green, Blue)), WRITE); Wie kann man sowas optimieren das man nicht immer SkinEngine davor schreiben muss.
Ich muss also immer zwischen SkinConfig und SkinEngine hin und her wandern und jedesmal den namen noch davor schreiben.

Wenns Dir wirklich nur um die Länge geht, sollte sich das so verkürzen lassen...

Delphi-Quellcode:

with SkinConfig, SkinEngine do
  zAEROCOLOR(zColorARGB(zGetTrackValue(zGetMainItem(ID_TRACK_OPACITY)), RGB(Red, Green, Blue)), WRITE);

[Reinhardtinho]

Mal so nebenbei:

Zitat von EWeiss:

Dafür habe ich in meiner SkinEngine Class eine extra Variable angelegt ebenfalls Public
function SK_CAPTIONFONTHEIGHT: Integer;

Das ist keine Variable, sondern eine Methode.

Zitat von EWeiss:

Delphi-Quellcode:

  
  zAEROCOLOR(..)
  zColorARGB(..)
  zCAPTIONFONTHEIGHT(..)
  SK_CAPTIONFONTHEIGHT(..)

Diese Namen für Methode halte ich für sehr verwirrend, die Zusammensetzung deutet nicht darauf hin, dass es Methoden sind, auf den ersten Blick sehen sie aus wie Variablen. Beschreibe doch einfach was diese Methoden machen. Zum Beispiel:

GetAeroColor
SetAeroColor
AeroColorToFoo
...

[EWeiss]

Mir ging es eigentlich um die Strukturierung des Quelltextes
Wie würdet ihr das denn anhand des beispiel machen ?

Irgendwie gehen wir am Thema vorbei.

gruss Emil

[Luckie]

Ich denke, da gibt es kein richtig oder falsch. Es ist hauptsächlich eine Geschmaksfrage, wie man es selbst am besten findet und man es selbst am besten lesen kann. Wenn du damit klar kommst, würde ich da nichts ändern.

Aber was die Benennung der Methoden angeht, würde ich den Tipp von Reinhardtinho beherzigen. Hinzukommt die Großschreibung der Bezeichner. Nur Großbuchstaben wählt man eigentlich nur für Konstanten, deswegen würde mich die Art der Bezeichnung bei dir ziemlich verwirren. Methoden benannt man nach dem was sie machen, bestehen also meistens aus zumindest einem Verb. Die ersten Buchstaben der Wortbestandteile schreibt man dann groß, wie auch schon im Beispiel:

Delphi-Quellcode:

GetAeroColor
SetAeroColor
AeroColor

Die Methoden sind GetAeroColor und SetAeroColor und haben entsprechend ein verb vorangestellt. Get für die Getter und Set für die Setter. Bei der Eigenschaft fehlt dann dieses Verb.

Bei dir würde das dann entsprechend aussehen:

Delphi-Quellcode:

GetCaptionFontHeight  // Getter
SetCaptionFontHeight  // Setter
CaptionFontHeight  // Property

Was soll eigentlich das kleine "z" vor den Methodennamen? Unter Delpjhi ist die Ungarische Notation eher nicht gebräuchlich, aufgrund der Typensicherheit der Sprache und der Codevervollständigung der IDE eigentlich auch überflüssig.

[mikhal]

Schau dir mal die Style Guides an, die von Borland mal empfohlen wurden. In deutsch findest du hier eine entsprechende Zusammenstellung.

Grüße
Mikhal

[EWeiss]

Zitat:

Was soll eigentlich das kleine "z" vor den Methodennamen? Unter Delpjhi ist die Ungarische Notation eher nicht gebräuchlich, aufgrund der Typensicherheit der Sprache und der Codevervollständigung der IDE eigentlich auch überflüssig.

Jo stimmt schon
Aber irgendwie komm ich damit nicht zurecht.
Es muss doch einen grund habe das ihr eure Classen anders aufbaut

Beispiel:

Delphi-Quellcode:

function TSkinConfig.zCAPTIONFONTHEIGHT(N, RW : Integer): Integer; 
begin 
   if RW <> 0 then 
    WasN := N; 

  Result := WasN; 

end;

Könnte man ersetzen wenn ich so überlege mit

property CaptionFontHeight: Integer read FGetCaptionFontHeight write FSetCaptionFontHeight; Theoretisch wäre das dass gleiche von der Funktionsweise.
Nur wo liegt der unterschied.
Ist es sinnvoller über property zu gehen oder über eine Funktion

gruss Emil

[EWeiss]

Zitat von mikhal:

Schau dir mal die Style Guides an, die von Borland mal empfohlen wurden. In deutsch findest du hier eine entsprechende Zusammenstellung.

Grüße
Mikhal

Werd ich mal tun nur bei einer Diskussion bleibt mehr hängen als wenn ich das jetzt lese ..
Geht auch nur Online.

gruss Emil

[Medium]

Es macht keinen all zu großen Unterschied. Properties sind ein sehr eleganter Weg das Geheimnisprinzip der OOP zu realiseren, und wie ich finde gerade in Delphi sehr angenehm implementiert. Getter/Setter Methoden ohne Properties würde ich in Delphi daher eher als nicht so schönen Stil ansehen, bei Sprachen die dieses Konstrukt nicht kennen sind sie halt der einzig sinnvolle Weg.
Das nette an Properties ist, dass man z.B. nur einen Weg (setzen/lesen) über eine Methode machen kann, und für den anderen Fall direkt auf die Variable verweist. Das spart in manchen Fällen einfach eine Methode die eh nur dem result den unveränderten Variableninhalt zuweisen würde.
Zudem werden vom Compiler für Properties noch zusätzliche RTTI Informationen erzeugt, die ab und an auch hilfreich sein können - aber das sind nun schon sehr spezielle Dinge.

Edith wollte den Hinweisen zur Benamsung nur noch ein wenig Nachdruck verleihen

[Luckie]

Man kann entweder mit der Property direkt das private Attribut abfragen und setzen oder man kann über private Methoden, den sogenannten Gettern und Settern gehen. Mit einem Getter oder Setter hat man die Möglichkeit die Daten noch zu verifizieren bevor man sie den privaten ASttributen zuweist bzw. bevor man sie ausgibt. Deswegen wähle ich immer den Weg über die Getter und Setter, auch wenn ich sie eigentlich nicht bräuchte, aber eventuell braucht man sie ja doch noch mal.