Mein Delphi-Style

[Jakob Ullmann]

Also ich finde, die Standards sind am Besten leserlich, weshalb ich mich weitgehend daran halte. Das heißt also, dass ich Anweisungen auf gleicher Ebene gleich einrücke (außer nach if, for, etc. folgt ein begin, dann ist das untereinander). Wenn ich ein Arument umbrechen muss, rücke ich das so ein, wie das erste Zeichen, das zum Argument gehört). Mich irritieren Großbuchstaben ebenfalls, da sie aber so häufig vorkommen, hab ich mich dran gewöhnt.

Bei Klassennahmen, etc. ist mir vor allem wichtig, dass sie selbsterklärend sind.

[Hansa]

Zitat:

Zitat von NamenLozer

Inwiefern sollte mich dein Delphi-Style interessieren?

Offensichtlich tut es das aber doch. 8)

Zum Thema : der Borland-Styleguide ist doch wirklich zu gebrauchen. Ich halte mich nur an einer Stelle nicht daran. So wie Satty.

Delphi-Quellcode:

if xy then
begin
...
end;

wird so geschrieben :

Delphi-Quellcode:

if xy then begin
...
end;

Und zwar aus zwei Gründen :

Bei hoher Verschachtelungstiefe fehlt manchmal ein end; oder es ist falsch eingerückt, eines zuviel etc. Interessant ist nun aber nicht, dass zu dem end; irgendwo ein begin steht, das ist ja wohl klar. Interessanter ist, ob das jetzt das for,while,if-end; ist.

Das zweite ist das Drucken, bzw. Bildschirmausgabe. Warum soll ich den Code unnötig aufblähen mit überflüssigen Zeilen ? Das gilt auch für eigentlich unnötige Leerzeilen. Der TE-Style ist allerdings auch übertrieben. Eine Variablen-Zuweisung hat nichts in der Zeile zu suchen, in der die Bedingung dafür steht. Wer sich allerdings jetzt zu 100 % an den Borland-Styleguide hät, der machts im Prinzip schon richtig.

[mkinzler]

Zitat:

wird so geschrieben :

Du scheibst es so, Ist aber kein Muss!
@Hansa: Also C-Style

[Luckie]

Zitat:

Zitat von Hansa

Bei hoher Verschachtelungstiefe

Dann hast du schon ein Problem mit dem Konzept und solltest dein Konzept überdenken. Siehe dazu "Clean Code".

Zitat:

Das zweite ist das Drucken

Wer drcukt Quellcode aus, um dann damit zu arbeiten?

Zitat:

Bildschirmausgabe

Wenn man seinen Code entsprechend strukturiert und in übersichtliche Funktionen aufteilt, ist auch das kein Problem.

[Hansa]

C-Style ist das ? :gruebel: Der ist dann eben auf meinem Mist gewachsen. :mrgreen: Gründe : siehe oben. Hatte sowieso noch was vergessen. Die Bezeichner. Hier sind ja immer schöne Buttons23 etc. zu begutachten. Die Prefixe klassifizieren ja schon vorab die Variablen. Deshalb gilt (wie gesagt nur bei mir) folgende Nomenklatur : btnWeiter, btnEnde... Dazu braucht man dann auch keinen extra-Kommentar. Um die Beschriftung etwas zu vereinfachen gibt es IDE-Tools wie GExperts oder CnPack. Ohne viel Aufwand kann man dann sinnvolle Namen vergeben (bzw. wird sanft dazu quasi gezwungen). Die Prefixe selber weichen glaube jedenfalls auch etwas von dem Borland-Styleguide ab. Edits haben ed und nicht edt usw. Labels sind die lbl, denn da gibt es ja noch Listboxen, also für die dann lb.

@roter Kasten (Luckie) : nachdem, was ich letztens gesehen habe, ist dieses Buch für die hier gedacht : :cat: . Prozedur maximal 2 Zeilen, oder wie ? Lächerlich. Also jetzt nicht Deine Ausssage, sondern das Buch. :mrgreen:

[Desmulator]

Nun mein Style ist recht einfach. Jedes Keyword wir immer klein geschrieben. Bezeichner tragen keine Prefixes, der Name sollte auf den Typ schließen lassen. Bezeichner werden in dem UpperCamelCase geschrieben, heißt erster Buchstabe groß, jedes neu Wort groß. Bezeichner von Typen beginnen immer mit T, Interfaces mit I, Pointer mit P, Exception mit E und Resourcestrings mit S.

Delphi-Quellcode:

procedure TMyObject.MyLittleMethod(Value : Cardinal);
var
  X, Y, Z : Extended;                // Gleiche Typen werden immer hintereinander geschrieben und nicht X : Extended; Y : Extended;
  Index : Cardinal; SubIndex : Byte; // Variablen, die gleiche Sinne haben, stehen hintereinander.
begin
  { Gedankliche Codesegmente werden so unterteilt. }
  X := 12; // InlineComments können stehen so wie wollen.
  Y := 45.8;
  Z := 7.33;

  // Wenn kein Platz, dann stehen die Kommentare drüber.
  for Index := 0 to Value do begin // Irgendwie hab ich mir angewöhnt die Zählervariable immer Index zu nennen.
  end;
end;

Wichtig ist auch die Leerzeichensetzung, nach jedem Komma ein Leerzeichen, vor jedem und nach jedem := : ein, zwischen klammern und Bezeichnern keine! Rechenoperatoren immer mit Leerzeichen abtrennen.

Dann gibts da noch sowas, dass kann nicht nicht erklären, ich verbinde gerne konstrukte mit einander. So sich andern die Haare streuben finde ich es einfach "schön", eine Art Kunst, es so zu schreiben. Beispiel:

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;

Man könnte fast sagen, ich baue eine Bindung mit meinem Code auf und nur, wenn er auch gut aussieht, ist er ein gute Code.

Delphi-Quellcode:

  if Count = 0 then Exit;
  for Index := 0 to Count - 1 do begin
    DisplayMode := GetDisplayMode(Index);
    if ( DisplayMode.Width = Width ) and ( DisplayMode.Height = Height ) and ( DisplayMode.RefreshRate = RefreshRate ) then begin
      Result := true;
      Exit;
    end;
  end;

Delphi-Quellcode:

  EffectHandle := nil;
  if FEffect.Bounded then begin
    IDirectSoundCaptureBuffer8(Effect.BoundedBuffer.Handle).GetObjectInPath(
      GUID_DSCFX_CLASS_NS, Effect.Description.ID, IID_IDirectSoundCaptureFXNoiseSuppress8, EffectHandle);
  end else Abort;

Delphi-Quellcode:

procedure TBaseObject.BeforeDestruction;
var Index : Cardinal;
begin
  BaseDropHandle(SystemHandle);
  if Length(Dependencies) > 0 then begin
    for Index := 0 to High(Dependencies) do
      if Dependencies[Index] <> nil then FreeAndNil(Dependencies[Index]);
  end; while frefcount > 0 do // Ich weiß nicht wieso, aber das while gehört hir hin.
    InterLockedDecrement(frefcount);
  inherited;
end;

Teilweise haue ich auch richtige Hammer raus, die ich aber grade nicht finden kann.

Edit: Gefunden xD :

Delphi-Quellcode:

  if AutoOpenFile then try
    Stream := TFileStream.Create(FileName);
    with Stream do case LoadTarget of
      ltWindow : LoadToWindow(Stream);
      ltMindmap : LoadToMindmap(Stream);
      else begin if Stream.Size = 0 then EmptyFile()
    end end else LoadFail := true;
  except
    ShowMessage('Fehler...');
  end;

[jfheins]

Wenn schon alle ihren Code zur Schau stellen mach ich das jetzt mal auch :mrgreen:

Ich bilde mir ein, relativ nah (bis auf 1-2 Sachen) am Styleguide zu programmieren, aber seht selbst ;)

Ich mache gerne sowas:

Delphi-Quellcode:

procedure TFtpBrowser.CreateItemFromFileInfo(const FileInfo: TFileInfo);
var
  ListItem: TListItem;
begin
  if FileInfo.Filename <> '.' then
  begin
    ListItem := FFiles.Items.Add;

    if FileInfo.FileType = 'Ordner' then
      if Fileinfo.Filename <> '..' then
        ListItem.ImageIndex := 0
      else
        ListItem.ImageIndex := 1
    else
      ListItem.ImageIndex := 2;

    ListItem.Caption := FileInfo.Filename;

    if FileInfo.Size > 1000000 then
      ListItem.SubItems.Add(IntToStr (FileInfo.Size DIV 1000000) + ' MB')
    else if FileInfo.Size > 1000 then
      ListItem.SubItems.Add(IntToStr (FileInfo.Size DIV 1000) + ' KB')
    else if FileInfo.Size > 0 then
      ListItem.SubItems.Add(IntToStr (FileInfo.Size) + ' Byte')
    else
      ListItem.SubItems.Add('n/a');

    ListItem.SubItems.Add(FileInfo.FileType);
    ListItem.SubItems.Add(FileInfo.Date);
  end;
end;

Also eher nicht kompakt sondern (imho) übersichtlich. Gerne mag ich auch das else if - man könnte auch einfach if schreiben, aber es ist ja doch irgendwie abhängig ...

Noch ein Beispiel:

Delphi-Quellcode:

procedure TFtpBrowser.DeleteFile (AFile: String; IsDir: Boolean);
begin
  if (IsDir and (AFile <> '.') and (AFile <> '..')) then
  begin
    try
      DeleteAll(AFile);
      FFtp.RemoveDir(FDir.Text + AFile);
    except
      TriggerLogEvent('Could not remove directory ' + AFile, etError);
    end;
  end
  else if (not IsDir) then
  begin
    try
      FFtp.Delete (FDir.Text + AFile);
    except
      TriggerLogEvent('Could not remove file ' + AFile, etError);
    end;
  end;
end;

vor und nach operatoren gehört ein Leerzeichen, vor die Klammer beim Funktionsaufruf aber nicht.

Schleifenindizies werden ab i durchnummeriert.

[Luckie]

Zitat:

Zitat von jfheins

Noch ein Beispiel:

Delphi-Quellcode:

procedure TFtpBrowser.DeleteFile (AFile: String; IsDir: Boolean);
begin
  if (IsDir and (AFile <> '.') and (AFile <> '..')) then
  begin
    try
      DeleteAll(AFile);
      FFtp.RemoveDir(FDir.Text + AFile);
    except
      TriggerLogEvent('Could not remove directory ' + AFile, etError);
    end;
  end
  else if (not IsDir) then
  begin
    try
      FFtp.Delete (FDir.Text + AFile);
    except
      TriggerLogEvent('Could not remove file ' + AFile, etError);
    end;
  end;
end;

Bei mir würde das so aussehen:

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;

Und RemoveFilesAndDir:

Delphi-Quellcode:

procedure TFtpBrowser.RemoveFilesAndDir(..);
begin
  if (not DeleteAll(AFile)) or (not FFtp.RemoveDir(FDir.Text + AFile)) then
    raise Exception.Create(...);
end;

So wird die Methode wesentlich übersichtlicher und man kann mit einem Blick erfassen, was passiert, an Hand der sprechenden Methodennamen.

Wobei noch zu überlegen wäre, ob man die Fehlerbehandlung nicht auch aus DeleteFile nimmt. Dann kann der Anwender des Codes selber entscheiden, was bei einem Fehler passiert. Ich würde es jedenfalls so machen. TriggerLogEvent wäre dann bei mir in einer eigenen Klasse, die man dem Programmierer mit an die Hand geben kann.

@Hansa: So meine ich das. Und wenn ein, zwei zeilen sinnvoll pro Funktion erscheinen, warum nicht.

[stoxx]

und ich würde mir den Code so formatieren, ich bevorzuge den Style von Satty allerdings mit 4er Einrückung. Man möge die Übersichtlichkeit im Vergleich zu Muhkuh selber vergleichen :-) Macht sich sehr übersichtlich bei längeren Blöcken. Die Einrückung ist immer wunderbar zu sehen.

Delphi-Quellcode:

if k = kMax then
    A[k] := A[k-1] / A[k];


if a = 0 then begin
    Result := 0
end else begin

    if a > 0 then
        Result := 1 else
           Result := -1;
end;

if Sender = mnPrintGraphOben then
    h := ro else
        h := rm;

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;

[stoxx]

die DeleteFile Formatierung finde ich persönlich höchst unübersichtlich. Ein Grundsatz bei uns. Ein "if .. then .. else" entweder komplett ohne ein "begin" und "end", wenn eine einzeilige Anweisungen reicht, oder alle beide Fälle in "begin- end" Blöcke.
In der DeleteFile Formatierung weiter oben würde man überhaupt nicht erkennen, in welchem Fall der Code nämlich einfach nix machen würde. (else Not isDir fehlt) Bei komplizierten Algorithmen kann das schwierig werden. Leerzeilen immer so, wie es am übersichtlichsten aussieht. Dass man den Code auch am "optischen" Eindruck wiedererkennt.


so sähe dass bei uns aus..

Delphi-Quellcode:

procedure TFtpBrowser.DeleteFile (AFile: String; IsDir: Boolean); 
begin
  if (IsDir and (AFile <> '.') and (AFile <> '..')) then begin

      try
          DeleteAll(AFile);
          FFtp.RemoveDir(FDir.Text + AFile);
      except
          TriggerLogEvent('Could not remove directory ' + AFile, etError);
      end;

  end else  begin

      if (not IsDir) then begin
          try
              FFtp.Delete (FDir.Text + AFile);
          except
              TriggerLogEvent('Could not remove file ' + AFile, etError);
          end;
      end;

  end;

end; // DeleteFile

edit:
bzw sehe ich gerade, dass der Code DeleteFile eine komplett "schiefe" Logik hat, und ich in sauber in einen IsDir und else IsDir unterteilen würde :-) .. (Den Fehler sieht man aber erst, wenn man "ordentlich" formatiert :mrgreen:
Eine IsDir Prüfung kann man sich sparen, was vor allen Dingen wichtig ist, wenn es um zeitkritischen Code geht.

nämlich so:

Delphi-Quellcode:

procedure TFtpBrowser.DeleteFile (AFile: String; IsDir: Boolean);
begin

  if (IsDir) then begin

     if  (AFile <> '.') and (AFile <> '..') then begin

          try
              DeleteAll(AFile);
              FFtp.RemoveDir(FDir.Text + AFile);
          except
              TriggerLogEvent('Could not remove directory ' + AFile, etError);
          end;
     end;

  end else  begin // else IsDir

      try
          FFtp.Delete (FDir.Text + AFile);
      except
          TriggerLogEvent('Could not remove file ' + AFile, etError);
      end;

  end;

end;