Mein Delphi-Style

[Chemiker]

Hallo,

ich schreibe auch bei einer Anweisung ein begin/end, dass ist zwar etwas mehr Tipparbeit, erhöht meiner Meinung aber die Übersicht. Ein weiterer Aspekt ist, dass beim Einfügen einer weiteren Befehls-Zeile besser klar wird was gemeint ist.

Delphi-Quellcode:

  StrMaNr:= TMSV1(MessStellenLst.Objects[i]).MaNr;
for i := 0 to MessStellenLst.Count - 1 do
begin
  if TMSV1(MessStellenLst.Objects[i]).MSAktiv then
  begin
    If StrMaNr = TMSV1(MessStellenLst.Objects[i]).MaNr then
    begin
      if StrMaNr <> TMSV1(MessStellenLst.Objects[i]).MaNr then
      begin
        iMaxMessStellen:= 0;
      end;
      inc(iMaxMessStellen);
      StrMaNr:= TMSV1(MessStellenLst.Objects[i]).MaNr;
    end;
  end;
end;

Bis bald Chemiker

[Hansa]

Zitat von stoxx:

außerdem sollte man Funktionen auch nach logischen Gesichtspunkten entwerfen...

Wenn das "auch" durch "nur" ersetzt wird, dann würde ich das unterschreiben. So aber nicht. Unterprogramme, also Funktionen / Prozeduren sollten wirklich nicht zu lang werden. Aber sie regelrecht zu atomisieren, das ist es auch nicht. Das reißt im Extremfall die Logik völlig auseinander. Und das mit 2-3 Zeilen erübrigt sich sowieso, sofern nur mal ein case gebraucht wird.

[Fridolin Walther]

Zitat von Dipl Phys Ernst Winter:

Welch ein redundanter Schwachsinn! Offenbar an einen geistig Behinderten gerichtet. So etwas habe ich in keinem Mathematikbuch gefunden, selbst wenn es Programme enthält.

Nunja, was will man von jemandem erwarten dessen Ego ihn offensichtlich dazu zwingt seine akademischen Titel im Benutzernamen zu verewigen ...

@Topic:
Ich benutz großteils den Stil von Luckie mit der Ausnahme, daß ich begin/end einfach und Codeblöcke doppelt indentiere:

Delphi-Quellcode:

procedure TFtpBrowser.DeleteFile(AFile: String; IsDir: Boolean); 
begin 
  if (IsDir and (AFile <> '.') and (AFile <> '..')) then 
    begin 
      try 
        RemoveFilesAndDir(...); 
      except 
        // Fehlerbehandlung 
      end; 
    end 
  else if (not IsDir) then 
    begin 
      try 
        Deletefile(..); 
      except 
        // Fehlerbehandlung 
      end; 
    end; 
end;

Ansonsten gehör ich zu der Fraktion, die der Ansicht sind, daß die Menschenlesbarkeit von Code im Vordergrund steht. Entsprechend gibts selten Funktionen länger als 60 Zeilen Code oder Verschachtelungen dessen Code derart weit indentiert ist, daß er von der Breite her nicht mehr auf den Bildschirm passt. Funktions- und Variablennamen sind selbsterklärend gewählt, weil mit Ausnahme von i als Schleifenzähler sich niemand etwas unter f, g, h oder z vorstellen kann. Dank Code Completion schreib ich ohnehin selten mehr als die ersten paar Buchstaben eines Identifier, so daß es vom Tippen her nur ein unbedeutender Mehraufwand ist.

Letztlich seh ich es aber wie die meisten hier: Man sollte den Stil nutzen der einem selbst am ehesten zusagt. Außer natürlich, man wird vom Arbeitgeber zu einem bestimmten Stil genötigt .

[Satty67]

Zitat von jbg:

Oder schreibt ihr wirklich folgenden Code und ändert ständig Delphis autogenerierte Methoden ab?

Delphi-Quellcode:

procedure Test; begin
  MyTest;
end;

Das jetzt nicht, auf keinen Fall... aber jede Regel kennt Ausnahmen

Glaube aber zu wissen woher das kommt:
if <Ausdruck> then begin hab' ich mir wohl bei Turbo Pascal für Dos angewöhnt. Noch wenig geübt, den Code in Häppchen aufzuteilen, war jede gesparte Zeile auf einem 25 Zeilen-Bildschirm ein Vorteil.

Seit man mehr Zeilen auf dem Bildschirm sieht, nutze ich das nicht für das freistehende "begin", sondern eben für Leerzeilen. Aber Leerzeilen brauche ich eben, um beim Lesen in der Zeile bleiben zu können. Ich kann im Code nicht so sicher lesen, wie in einem Roman-Text.

[Meflin]

Zitat von Luckie:

Gerade Leerzeilen sind ein Zeichen dafür, dass man den Code aufteilen sollte, deswegen meine Aufteilung.

Ach was. In Funktionen füge ich zwischen zusammengehörige Blöcke auch Leerzeilen ein (z.B. Initialisierung - Berechnung - Aufräumarbeiten). So, hat man dann also z.B. 3, 5 und 2 Zeilen, sehr viel lesbarer, und daraus soll ich nun 3 Funktionen machen

[Mithrandir]

Zitat von Dipl Phys Ernst Winter:

Delphi-Quellcode:

  if k=kMax then A[k]:= A[k-1]/A[k]
  if a=0 then Result:= 0 else if a>0 then Result:= 1 else Result:= -1;
  if Sender=mnPrintGraphOben then h:= ro             // 'Drucken|Graph oben'
                             else h:= rm;            // 'Drucken|Graph unten'                       
  for k:= 0 to kMax do A[k]:= 0;
  for i:= 1 to iMax do begin temp:= A[i]; A[i]:= B[i]; B[i]:= temp end;
  for i:= 2 to m do begin
    for k:= 1 to i-1 do B[i]:= B[i] - A[r(i,k)]*B[k];
    B[i]:= B[i]/Abs(A[r(i,i)]) end;
  with Image1.Canvas do begin
    MoveTo(DL, D0 - Round(sy*(F(xMin)-yMin)));
    for i:= 0 to 320 do begin
      x:= xMin + i*dx;
      LineTo(DL + 2*i, D0 - Round(sy*(F(x)-yMin))) end end;

Und so unterscheiden sich die Geschmäcker. Für mein Verständnis sieht der obige Code ziemlich - sit venia verbo - dahingerotzt aus.

[ULIK]

Hallo Ernst,

Zitat von Dipl Phys Ernst Winter:

Für mich kann das einzige Kriterium nur die Lesbarkeit des Programmcodes sein!

Zitat:

for intZaehler:= intAnfangZeile to intEndeZeile do arrBildfeld[intZeile, intZaehler]:=... bzw. aus der DP:
for iFor:= ... Welch ein redundanter Schwachsinn! Offenbar an einen geistig Behinderten gerichtet. So etwas habe ich in keinem Mathematikbuch gefunden, selbst wenn es Programme enthält.
Der in der Mathematik übliche Bezeichnungsweise einer Matrix Bik folgend schreibe ich

Delphi-Quellcode:

for i:= ia to ie do
  for k:= ka to ke do B[i, k]:=...

mit Zeilenindex i und Spaltenindex k in den Grenzen ia, ie und ka, ke.
Da ist doch wohl alles erklärt! Der Code wird kompakter, übersichtlicher und besser lesbar.

Mit den beiden Quotes widersprichst Du Dir schon etwas: Lesbarkeit heißt doch auch, daß ein fremder Programmierer den Code schnell versteht, auch wenn er zuvor noch nie damit etwas gemacht hat. Deine Variante mag zwar der mathematischen Schreibweise besser entsprechen, nur setzt sie voraus, daß der Leser den genauen Context kennt. Bei arrBitFeld kann ich anhand des Namens schon identifizieren, um was es da geht. Bei 'B[i,k]' geht das ja wohl schlecht.

Ich hatte mal das Vergnügen, in einer Verschnittoptimierung eine Fehler zu suchen, einem Bereich, in dem ich bis dahin nichts gemacht hab. Sprich ich kannte das Programm und die Theorie nicht. Selbiges war genau in diesem mathematischen Stil programmiert, also die math. Symbole als Variablennamen. Der Code war nicht lesbar, erst nachdem mir der ursprüngliche Programmierer mal etwas mehr Theorie zum Lesen gegeben hat, hab ich dem Zeug einigermaßen folgen können (und die erste Amtshandlung war, das Zeug vernünftig zu benennen)

Seit dem leg ich sehr viel Wert drauf, Variablennamen vernünftig zu benennen (und wenn sie dann PDFCoordinatesIncludingPageRotation: TRect heissen)


Grüße,
Uli

[Daniel]

Zitat von Dipl Phys Ernst Winter:

[...]
Welch ein redundanter Schwachsinn! Offenbar an einen geistig Behinderten gerichtet. So etwas habe ich in keinem Mathematikbuch gefunden, selbst wenn es Programme enthält.
[...]

Lüd (plattdeutsch für "Leute"),

ich lese solche Themen hin und wieder recht gern, weil man so die Gelegenheit hat, auch mal kritisch den eigenen Stil zu hinterfragen und Dinge ggf. besser zu machen.

Es darfallerdings nicht sein, dass wir dabei -auch wenn wir ein Stilmittel vollständig ablehnen- eine derart harte Kritik äußern wie im oben zitierten Abschnitt.

[Luckie]

@stoxx: Man muss sie ja nicht zwangsweise auf zwei Zeilen runterbrechen. Aber so bald ich leerzeilen einfüge, ist das ein zeichen, dass ich innerhalb einer Funktion logisch getrennte Codeblöcke habe und das ist ein zeichen dafür, dass diese Funktion mehr als eine Funktion erfüllt. da es aber besser ist, wenn eine Funktion auch wirklich nur eine aufgabe erfüllt, sollte man hier mehrere Funktionen raus machen.

[himitsu]

solange es eh klar ist, daß die Einzelteile eh nie wo anders mal Wiederverwendung finden könnte, dann mach ich mir lieber nur 'ne Leerzeile rein, anstatt gleich eine ganz neue Funktion (mehrere neue Zeilen) irgendwo anders hinzulegen.

Außerdem muß die Leerzeile kein Zeichen dafür sein, daß dise Funktion mehrere Funktionen erfüllt ... man kann sich auch nur die "eine" Funktion in mehrere logische Teilabschnitte aufteilen.