Mein Delphi-Style

[himitsu]

Zitat:

Delphi-Quellcode:

function BaseCloseHandle(Handle : TBaseHandle) : Boolean; stdcall;
begin
  if Handles[Handle] = nil then Result := false
  else begin case Handles[Handle]^.HandleType of // Besonders diese Zeile.
      bhtObject : Handles[Handle]^.ObjectPointer.Free;
      bhtWindowsHandle : Windows.CloseHandle(Handles[Handle]^.Handle);
      bhtCallback : Handles[Handle]^.Callback();
    end;
    FreeMem(Handles[Handle], SizeOf(TBaseHandleData));
    Handles[Handle] := nil;
    Result := true;
  end;
end;

bei gleichen/ähnlichen Gruppen rücke ich es mir gern mal übersichtlicher ein

Delphi-Quellcode:

// Handles[Handle].xyz   // hier muß man nicht dereferenieren ... Delphi bemeckert das sogar

Function BaseCloseHandle(Handle: TBaseHandle): Boolean; StdCall;
  Begin
    If Handles[Handle] <> nil Then Begin
      Case Handles[Handle].HandleType of
        bhtObject:        Handles[Handle].ObjectPointer.Free;
        bhtWindowsHandle: Windows.CloseHandle(Handles[Handle].Handle);
        bhtCallback:      Handles[Handle].Callback;
      End;
      FreeMem(Handles[Handle], SizeOf(TBaseHandleData));
      Handles[Handle] := nil;
      Result          := True;
    End Else Result   := False;
  End;

// oder

Function BaseCloseHandle(Handle: TBaseHandle): Boolean; StdCall;
  Begin
    Result := Handles[Handle] <> nil;
    If Result Then Begin
      Case Handles[Handle].HandleType of
        bhtObject:        Handles[Handle].ObjectPointer.Free;
        bhtWindowsHandle: Windows.CloseHandle(Handles[Handle].Handle);
        bhtCallback:      Handles[Handle].Callback;
      End;
      FreeMem(Handles[Handle], SizeOf(TBaseHandleData));
      Handles[Handle] := nil;
    End;
  End;

[Luckie]

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

[jfheins]

Zitat von Luckie:

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

Oh ...

Also ich füge dich gerne auch einfach mal so ein ... hier mal ne rekursive Funktion:

Delphi-Quellcode:

procedure TFtpBrowser.ChangeDir (ADir: String);
begin
  Working := True;

  if (ADir = '.') or (ADir = '') then
  begin
    TriggerLogEvent('Receiving directory listing', etStatus);
    FFiles.Clear;
    CreateDirectoryListing;
    TriggerLogEvent('Directory listing complete', etStatus);
  end
  else if ADir = '..' then
  begin
    if FDir.Text <> '/' then
    begin
      FDir.Items.Delete(FDir.ItemIndex);
      FDir.ItemIndex := Pred (FDir.Items.Count);
      FFtp.ChangeDir(FDir.Text);
    end;
    ChangeDir('.');
  end
  else
  begin
    if FDir.Items.IndexOf(ADir) > -1 then
    begin
      while FDir.ItemIndex <> Pred(FDir.Items.Count) do
        FDir.Items.Delete(Pred(FDir.Items.Count));
    end
    else
      if (copy(ADir, 1, 1) = '/') and (copy(FDir.Text, 1, 1) = '/') then
        Delete(ADir, 1, 1);

      if (copy(ADir, 1, 1) <> '/') and (copy(FDir.Text, 1, 1) <> '/') then
        ADir := '/' + ADir;

      if copy(ADir, length (ADir), 1) <> '/' then
        ADir := ADir + '/';

      FDir.ItemIndex := FDir.Items.Add(FDir.Text + ADir);

    try
      FFtp.ChangeDir(FDir.Text);
      ChangeDir('.');
    except
      TriggerLogEvent('Could not open directory "' + FDir.Text + '"', etError);
    end;
  end;

  Working := False;
end;

Naja - jedem das seine

(Mir hat in dem Projekt die Anzahl der Funktionen schon gereicht, jetzt noch Sachen in eigene 3-Zeiler auslagern und ich hätte beim Funktionsbaum nicht mehr durchgeblickt ...)

[mschaefer]

Die Mathematik ist expliziter Definiert. Bei Formatierungen dürfte sich da eine gewisse Gewohnheit im Team herausbilden und ich sehe eigentlich keinen ernsthaften Grund jede Variante zu Bewerten. Tue ich auch hier nicht, denn der Titel heist ja mein Delphi Style.

Es würde sich bei der Formatierung aber anbieten einen Stil zu wählen, der von den automatischen Formatprogrammen ausgegeben werden kann, damit man auch Fremdcode in eigenen Projekte einpflegen kann ohne alles neu anzufassen.

Grüße in die Runde // Martin

[DataCool]

Hi,

ich mache es genauso wie Satty, Hansa, Mkinzler und wahrscheinlich viele andere:

Borland Styleguide bis auf das begin in der nächsten Zeile.

Das Begin am Ende der Zeile ist meiner Meinung nach :

- übersichtlicher, man sieht gleich ob das "end" zu einen "if", "for", "while", ... gerade bei längeren Code
@Luckie: längerer Code ist zwar "unschön", aber nicht immer lässt sich eine procedure/function auf 2 Zeilen runter brechen

- platzsparend

Aber im Endeffekt, soll es jeder so machen wie er es am besten findet,
wer seinenStil noch nicht gefunden hat sollte sich den Style Guide anschauen.

Greetz Data

[stoxx]

Zitat:

und ich sehe eigentlich keinen ernsthaften Grund jede Variante zu Bewerten. Tue ich auch hier nicht

schade .. jeder hat doch so seine eigenen Gedanken, warum er etwas tut. Die meisten zumindest. Was ich nur nicht machen würde, einfach einen Style zu übernehmen, weil jemand gesagt hat, es müsse so sein. Niemals

[stoxx]

@Luckie: längerer Code ist zwar "unschön", aber nicht immer lässt sich eine procedure/function auf 2 Zeilen runter brechen außerdem sollte man Funktionen auch nach logischen Gesichtspunkten entwerfen (welche Dinge könnte man wiederverwenden mit welchen Aufrufparametern etc. ), nicht so sehr nach optischen Punkten und Attributen wie "Codezeilen". (es soll ja auch große Monitore mit viel Platz und Übersicht geben
Desweiteren ist es manchmal sinnvoll, bei zeitkritischen Stellen einen zusätzlichen Funktionscall zu sparen.

[DataCool]

@stoxx: ^^^Absolut richtig ^^

[Muetze1]

Zitat von DataCool:

Das Begin am Ende der Zeile ist meiner Meinung nach :

- übersichtlicher, man sieht gleich ob das "end" zu einen "if", "for", "while", ... gerade bei längeren Code
@Luckie: längerer Code ist zwar "unschön", aber nicht immer lässt sich eine procedure/function auf 2 Zeilen runter brechen

- platzsparend

1. Nicht jedes IF hat ein begin. Was muss ich also tun? Ich muss mit lesen deiner Zeilen immer nach rechts schauen, ob sich da ein begin versteckt: sehr schlecht! Stört den Lesefluss des Codes und stört beim Debuggen, da es eben nicht klar ist, dass jedes IF ein begin hat.

Gleiches gilt für die Schlüsselwörter FOR und WHILE. Deshalb schreibe ich begin immer in die nächste Zeile. Ich lese die aktuelle Einrückungsspalte gerade runter bzw. scrolle beim lesen entsprechend. Wenn ich nun z.B. eine IF Bedingung finde und ich anhand der Bedingung schon erkenne: Der Fall ist für derzeit uninteressant, dann erkenne ich am begin unter dem IF, ob ich die Spalte runterschauen muss bis zu einem END in der Einrückung oder ich schaue gleich 2 Zeilen tiefer (eine Zeile ist ja der bedingte Code).

2. Platzsparend? Oh, du arbeitest noch 52 MB Platten? Oder warum muss man heute noch Platz sparen? Umweltschutz? Wenn mehr Code ohne Leerzeilen, desto weniger verbraucht die Hintergrundbeleuchtung von deinem Display? Ich bitte dich...

Dem Compiler ist es vollkommen egal, also können wir so schreiben, dass es leicht zu lesen und zu verstehen ist. Mit Einrückungen und Leerzeilen wird die Lesbarkeit des Codes erhöht - also für den Menschen. Dem Compiler ist es Wurst - und für mich als Leser sage ich dir: Ich nehme lieber ein paar Leerzeilen in Kauf - für mich musst du kein Platz sparen.

Leerzeilen sind auch eine gute Möglichkeit funktionale Codeabschnitte von einander zu trennen. Aber: nie mehr als eine Leerzeile!

3. Allgemein: Leute die den bedingten Code z.B. einer IF, While etc direkt in der selben Zeile hinten dran schreiben, haben noch nie wirklich debuggen müssen. Ich kann beim debuggen niemals sehen ob der Code nach der Bedingung ausgeführt wurde oder nicht. Ich kann diesen schlecht evaluieren, etc. Die Krönung ist dann meist noch den Else Zweig auch noch hinten dran. Dann was vollends nicht mehr, was nun ausgeführt wird.

Und nun kommen die Leute, welche behaupten, die Bedingungen sind immer auch zur Debugzeit evaluierbar, weil Optimierungen nutzt man nicht im Debug Kandidaten. Denen nur eins:

a) man debuggt Fehler meistens an einem Binary, welches Optimierung an hat. Würde man den Fehler vorher schon finden, bräuchte man ihn nicht debuggen...
b) Debuggt mal z.B. Delphi Code in der C++ Personality oder C++ Code, u.a. STL. Dies wird einen schnell dazu bringen das ganze in einzelne Zeilen zu verfrachten.
c) Ich muss nicht beim debuggen extra Zeit damit verschwenden die Evaluierung der Bedingung nach zu vollziehen um heraus zu finden, ob die Bedingung nun wahr oder falsch ergibt. Dies sehe ich mit einmal F8 sofort, da die Zeile in die er geht mir anzeigt was er evaluiert hatte.

/EDIT:
Ziel sollte immer Effizienz sein, mein AG bezahlt mich nicht für's Romane lesen. Und noch weniger gerne bezahlt er mich für's Code formatieren...

Und nochmal ein paar Regeln zusammengefasst...

[jbg]

Zitat von DataCool:

Borland Styleguide bis auf das begin in der nächsten Zeile.

Verstoßt ihr dann nicht bei jeder "procedure" und "function" gegen eure eigene Regel? Oder schreibt ihr wirklich folgenden Code und ändert ständig Delphis autogenerierte Methoden ab?

Delphi-Quellcode:

procedure Test; begin
  MyTest;
end;

Zitat:

Aber im Endeffekt, soll es jeder so machen wie er es am besten findet,
wer seinenStil noch nicht gefunden hat sollte sich den Style Guide anschauen.

Wenn man, wie ich, oft in der RTL, VCL und VisualCLX unterwegs ist/war und man nicht laufend den von Delphi generierten Code abändern will, also faul ist, dann gewöhnt man sich den Borland-Stil ähm CodeGear-Stil irgendwann mal an. Vor allem wenn man als junger Hüpfer die Handbücher (die es in den 90ern noch gab) zum erlernen der Sprache genutzt hat.