Delphi’s Object Pascal Style Guide erneuert

[Uwe Raabe]

Zitat von ConstantGardener:

<OT> Formatierung ist die eine Sache, wichtiger wäre, das LSP das gleiche Delphi/Object Pascal spricht bzw. versteht. Aber so langsam denke ich das werden wir nicht mehr erleben.</OT>

Das gleiche wie was?

[himitsu]

Compiler, ErrorInsight, CodeInsight, HelpInsight, Refactoring, die Änderungen vom FormDesigner oder synchronisierte Codeändeungen aus den Projektoptionen, usw.
Also alles mit der selben Syntax aus'm LSP arbeitet.

[himitsu]

So Copyrightzeugs/Unitbeschreibungen mach ich inzwischen ins PasDoc/XMLDoc, anstatt in einen komischen Kommentar.
Theoretisch könnte das dann im HelpInsight/CodeVervollständigung zum Unitnamen angezeigt werden (wenn es funktionieren würde) oder bei der Generierung einer Dokumentation oder Hilfe genutzt werden.

[Der schöne Günther]

Cool, ich bin mal gespannt ob ich etwas finde über das man sich so fanatisch streiten kann wie Tabs vs. Spaces.


Edit:

Zitat:

Never use tab characters

(Quelle)
👿 AAAAaaaaaa


PS: Wenn ich es beim Überfliegen richtig sehe dann habt ihr euch ja zum Glück auf eine doch sehr brauchbare Formatierungsvorgabe für anonyme Methoden geeinigt. Was man manchmal seht wie manche Leute die in den Code quetschen oder ausrichten, da rollen sich einem die Fußnägel hoch...

[himitsu]

http://docwiki.embarcadero.com/RADSt...te_Space_Usage

Nee nee nee, das geht so.

Delphi-Quellcode:

if DoSomething then
  {$IFDEF MSWINDOWS}MessageBox{$ELSE}WriteLn{$ENDIF}('Hello');

Das mit den Anonymen mach ich auch schon so.
Nur manchmal kommt die ProzedurDeklaration mit auf die selbe Zeile (wenn keine/wenige/kurze Parameter und die restliche Zeile davor auch kurz ist), aber das begin-end ist dennoch auf einer eigenen Zeile und immer eingerückt.

[jbg]

Was ist denn mit dem "end;" vom "case" los. Das gehört mir persönlich immer auf die Ebene vom "case" und nicht wie im neuen Style Guide, wenn ein "else" Zweig vorhanden ist, eingerückt.
http://docwiki.embarcadero.com/RADSt...phi_Statements

Neuer Style Guide:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
  else
    ...
  end; // huch?

So mache ich das:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
else
  ...
end;

[himitsu]

Ich rücke das ELSE genauso ein, wie oben die Werte, denn die gehören ja zusammen,
aber das letzte END kommt natürlich unters CASE.

BEGIN-END bei den Werten rücke ich aber (meistens) nicht nochmal ein.
BEGIN hinter : und END unter den Wert.
Somit ist Code, egal ob mit oder ohne BEGIN-END oder im ELSE, auch immer auf der gleichen Ebene.

Ein BEGIN hinter ELSE und dazu ein eigenes END ist ja optional, aber das schreib ich dennoch, wenn mehr als eine Zeile ... dann passt das mit der Einrückung auch gleich viel besser.

[KodeZwerg]

Zitat von jbg:

Was ist denn mit dem "end;" vom "case" los. Das gehört mir persönlich immer auf die Ebene vom "case" und nicht wie im neuen Style Guide, wenn ein "else" Zweig vorhanden ist, eingerückt.
http://docwiki.embarcadero.com/RADSt...phi_Statements

Neuer Style Guide:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
  else
    ...
  end; // huch?

So mache ich das:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
else
  ...
end;

Ich meist so:

Delphi-Quellcode:

case ch of
  '0': begin
         ...
       end;
  else
    ...
end;

[Rollo62]

Zitat von himitsu:

http://docwiki.embarcadero.com/RADSt...te_Space_Usage

Ich hab da gerne meine eigenen Regeln, ich nenne das "luftiger Stil", der besseren Lesbarkeit wegen.

Zitat:

Before or after a .(dot) operator

Möglichst ":=" und "=" untereinander, möglichst zusammenhängende Terme ausgerichtet.
Logische Verknüpfungen möglichst separiert, mit vorangestelltem operator.
Möglichst "luftiges" Design durch Spaces in () und [].

Delphi-Quellcode:

  Obj1______________ := TObj1.Create;
  Obj1.___Field1____ := True;
  Obj1.___Field2____ := False;
  //
  Obj1______________ := TObj1.Create;
  ObjNew2.Field3____ := True;
  ObjNew2.Field4____ := False;

  Obj1.___Liste[ 0 ] := 'null';
  Obj1.___Liste[ 1 ] := 'eins';

  if____________( Obj1.___Field1 =_ ObjNew2.Field1 )
    ____and_____( ObjNew2.Field2 <> Obj1.___Field2 ) 
    _// and_____( ObjNew2.Field1 <> Obj1.___Field2 )    //<== So kann man mal schnell Terme ein/ausschalten, und behält doch den Überblick
    ____and not ( Obj1__________ =_ ObjNew2_______ ) then
  begin
  end;

Ja, das ist gewöhnungsbedürftig, aber der Compiler hat sich noch nie beschwert und die Lernkurve ist flach

Edit:
Musste es mit ___ verunstalten, wg. der Forensoftware, damit man den Effekt sieht.

[himitsu]

Nee, nach Punkten trenn ich nicht (keine Leerzeichen reingemischt, *1), aber dahinter richte ich bei mehreren Zuweisungen auch die := immer untereinander aus.

1) außer bei langen Ausdrücken ein Zeilenumbruch vor dem Punkt, also Punkt in neuer Zeile, damit man sieht dass es eine Fortsetzung ist (und natürlich eine Stufe eingerückt).