Delphi’s Object Pascal Style Guide erneuert

[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.

[Rollo62]

Zitat von TiGü:

Das Auge muss doch so unnötig lange Wege zurücklegen.

Das Gehirn "sieht" zusammenhängende Muster aber sofort und viel schneller als den Sinn in einem Zeichenhaufen zu finden,
da wandert nicht viel über den Bildschirm.
Darum geht es.
Ausserdem sollen die Augen ja wandern, und nicht nur auf einen Punkt starren, darüber mache ich mir weniger Sorgen

Muss man nicht so machen, aber probier es halt einfach mal aus, nach einiger Zeit merkst Du die Vorteile.

Ich benutze mittlerweile auch alle Indents 4 statt 2 (das kommt ursprünglich aus Java, glaube ich).
Auch dass mach den Stil "luftiger", und die Umbrüche sind für das Gehirn viel schneller und leichter erfassbar.

[Benmik]

Zitat von TiGü:

Das Auge muss doch so unnötig lange Wege zurücklegen.
Das ist keine Tabellenkalkulation mit Spalten.
Zeile fünf hat (visuell) nichts mit Zeile 24 zu tun.

Und warum gibt es dann überhaupt Darstellungen in Tabellenform? Dort haben die Zeilen oft auch nichts miteinander zu tun. Auge und Kopf sind bei einer visuell gegliederten Anordnung viel schneller.

Embarcadero weiß schon sehr genau, warum es Style Guides und nicht dollymäßig Style Commandments veröffentlicht. Obwohl theoretisch völlig unbedeutend, da funktionell ohne Wirkung, erhitzen sich an der Formatierung regelmäßig die Gemüter. Die Programmiererzunft besteht halt tendenziell aus Leuten, die nicht nur eine ausgeprägte Meinung haben, sondern auch feste Überzeugungen hinsichtlich der Wertigkeit und der wünschenswerten allgemeinen Verbindlichkeit ihrer persönlichen Meinungen. Ich als Hobbyprogrammierer würde mich von Delphi abwenden, wenn die Style Guides technisch verbindlich gemacht würden. (Würde Emba wohl verschmerzen.) Ich bin angenehm überrascht, dass einige meiner Vorlieben auch von Profis geteilt werden. Und um TiGüs Frage zu beantworten: Ich habe mir für die Ausrichtung eigens ein kleines Programm geschrieben, das geht also ratzifatzi.

Ich würde an Embas Stelle den Formatierer stark aufwerten und in ein eigenes, ausgewachsenes Programm stecken, das extrem benutzerfreundlich wäre. Ich habe den Verdacht, dass im Programmiergeschäft 40% der Arbeitszeit damit verbracht werden, fremden Code unter einer Flut von abwertenden Bemerkungen umzuformatieren. (Dieser Verdacht ist durch die Lektüre dieses Forums entstanden.) All die Zeit und das ständige Sich-Ereifern könnte man sich sparen: Jeder hat seine persönliche Vorlage parat, einmal STRG+D und der Code ist genau nach persönlichem Gusto. Gibt ja auch die Bibel in ganz verschiedenen Ausführungen, und da wird ja auch jeder selig.

[Stevie]

Wenn die einzige Sorge im Code ist, ob da nun das end um 2 zu viel oder zu wenig eingerückt oder das begin am Ende der vorherigen Zeile steht oder in einer neuen, dann wäre das ja schon nahe an der Perfektion.

Fakt ist, dass der Code, der in Delphi mitgeliefert wird, durchaus sehr gut lesbar ist. Das hat aber in den letzten Jahren leider durch Nichtbeachtung des vorhandenen Guides abgenommen, was auch durch den Zukauf von Fremdcode (ich schaue euch an, FMX und FireDAC) und externe Entwickler für bestimmte Projekte entstand. Aber daran ist auch nicht nur die Formatierung schuld sondern oft auch die Gesamtarchitektur und verschwurbeltes Design und das ist viel wichtiger als ob da nun 2 oder 4 eingerückt wird, wenn das wenigstens konsistent ist.

Das heißt, auch wenn öffentlich zur Verfügung gestellt, ist der Guide mehr für interne Zwecke und solche, die für Embarcadero Code erstellen.

[stahli]

Natürlich gibt es wichtigere Punkte bei der Programmierung als die Codeformatierung.

Aber wenn man ohne Aufwand eine "übersichtliche Formatierung" einstellen kann, dann sollte man das m.E. auch tun.

Im Team muss man sich natürlich einigen, was "übersichtlich" ist bzw. sich getroffenen Regelungen unterordnen.