Delphi’s Object Pascal Style Guide erneuert

[himitsu]

Zitat von Jasocul:

Bei mehrzeiligen Bedingungen weiche ich vom Standard ab:

Delphi-Quellcode:

if bla1 and
   bla2 and
   bla3 then
begin
  ...
end

wobei ich hier die and/or/+/... vorne hab,
also wie bei den Punkten, damit man sieht was die neue Zeile macht und nicht erst darüber hinten suchen zu müssen.

Die Ausrichtung mit unterschiedlich langen AND und OR ist zwar bissl "hakelig", aber da kommt dann einfach ein Leerzeichen hinters OR.


Klar, bei dir passen and und then natürlich optisch besser zusammen,
aber auch wenn Andere auch das THEN auf eine neue Zeile unters IF machen, so bleibt es bei mit hinten (nach dem THEN, eventuell mit BEGIN-END, sieht man ja an der Einrückung, dass dort hinten ein THEN stehen muß)

[Frickler]

Zitat von KodeZwerg:

Ich meist so:

Delphi-Quellcode:

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

Kommt bei mir immer drauf an, wie lang die Labels sind.

Kurze Labels:

Delphi-Quellcode:

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

Lange Labels:

Delphi-Quellcode:

case aufzaehlungstyp of
  atZiemlichLangerName:
    begin
      ...
    end;
  atAndererNochVielLaengererName:
    begin
      ...
    end;
  else
    ...
end;

[KodeZwerg]

@Frickler: Ja, das geht so auch in Ordnung für mich. Mir war es halt wichtig zu zeigen wo mein "else" steht.

[perpeto1234]

Es wäre dann ja mal schön, wenn der Code-Formatter (Strg+D) nicht bei Inline-Variablen Zeilenumbrüche ergänzen würde. Das nervt mich so unglaublich. Früher war es eine Wohltat "Strg+D" zu hämmern.. aber das habe ich mir nur leider deshalb abgewöhnt.

Aus:
var Zahl := 1; Wird:

Delphi-Quellcode:

var
  Zahl := 1;

Toll!

[Stevie]

Zitat von Uwe Raabe:

Eine wichtige Erkenntnis aus den internen Diskussionen um den Style Guide war übrigens: Wähle die Regeln so, dass der interne Formatter es umsetzen kann.

Ich bin mir gar nicht sicher, ob das für den neuen Style Guide überhaupt gilt.

Wenn man jetzt bloß jemanden kennen würde, der den Sourcecode für den Formatter hat und den anpassen könnte

[himitsu]

Situationsbedingte Ausnahmen/Abweichungen sind für so Automatiken aber auch nicht immer leicht.

Je nach umgebendem Code passe ich meine Formatierung in Nuancen teilweise etwas an (Leerzeichen, Zeilenumbruch und Einrückung)

Beim VAR in Prozedurheadern und global ebenso mit Zeilenumbruch,
aber als Inline natürlich auch einzeilig.


z.B. bei "massenhaften" Parameterübersetzungen mach ich den Code direkt hinters THEN und THEN untereinander ausgerichtet,
aber wenn nur 1 oder 2 solcher Zeilen, oder wenn das im IF länger, dann auch mit Zeilenumbruch nach dem THEN.

Delphi-Quellcode:

if A then Include(C, D);  // bzw. C := C + [D]; oder sowas
if B then Include(E, F);
...

[stahli]

Also ich will auf jeden Fall eine Lösung, die komplett auf Knopfdruck funktioniert.
Notfalls würde ich auch mit ein paar Kleinigkeiten leben, die mir nicht ganz gefallen. Einiges kann man ja auch optional einstellbar machen.
Auf keinen Fall würde ich irgendwas händisch zurecht schieben.

Meinen Formatierer überarbeite ich gerade nochmal (läuft ganz gut).
Ich will zwar genau zu dem Ergebnis kommen, das ich schon erreicht hatte aber mein jetziger Weg kommt mit weniger Spezialbehandlungen aus als der letzte und ermöglicht auch eine bessere Codevervollständigung und Sortierung.

Eine Schwierigkeit ist z.B. dass ich auskommentierten Code als echten Code interpretiere und formatiere.
Das Ausrichten von bestimmten Codestellen (z.B. ":=") untereinander will ich unbedingt haben. Das finde ich sehr übersichtlich und hilfreich.

[TiGü]

Zitat von Rollo62:

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.

Puh, dass ist aber schon visueller Horror sondergleichen.
Das Auge muss doch so unnötig lange Wege zurücklegen.
Na ja, jeder Jeck ist anders.

Ich habe Programmierer und Softwareentwickler noch nie verstanden, die von oben nach unten etwas ausrichten.
Das ist keine Tabellenkalkulation mit Spalten.
Es sind zeilenbasierte An- und Zuweisungen.
Zeile fünf hat (visuell) nichts mit Zeile 24 zu tun.

Delphi-Quellcode:

  ObjNew2.Field3____ := True;
  ObjNew2.Field4____ := False;

Allein hier bekommt man doch voll die Krise, wenn Field4 umbenannt/refaktorisiert wird nach bspw. LongField4Name.
Wird dann überall angefangen händisch (!) die Leerzeichen anzupassen?
Wer bezahlt das?

[DieDolly]

Die meiner Meinung nach einfachste und beste Lösung ist, sich direkt die Schreibweise anzugewöhnen die von STRG+D vorgegeben wird.
Das mit den Leerzeichen, das ist der absolute Horror, schlimmer gehts nicht.

[stahli]

Mein Formatierer macht das Blockweise (siehe Screenshot).

Optional könnte man z.B. noch regeln, dass Sprünge über eine bestimmte Anzahl (sehr geringe Einrückung zu sehr weiten Einrückungen) nicht toleriert werden:

Delphi-Quellcode:

I__: Integer;
IYY: Integer;
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ: Integer;
IYYZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ______: Integer;

Aktuell würden die ersten zwei Zeilen mit nach rechts ausgerichtet, was man aber durch eine Leerzeile verhindern könnte. Alternativ wäre wie gesagt auch eine Option möglich, die solche großen Sprünge verhindert.


Eine Ausrichtung untereinander von Hand würde ich auf keinen Fall machen aber eine solche Ausrichtung auf Knopfdruck finde ich nützlich.