Delphi’s Object Pascal Style Guide erneuert

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

[Rollo62]

Zitat von himitsu:

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

Ja so fing das Symptom bei mir auch an

[Jasocul]

Ausrichtung von Zuweisungen mache ich auch am ":=".
Bei mehrzeiligen Bedingungen weiche ich vom Standard ab:

Delphi-Quellcode:

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

Analog bei ähnlichen Konstrukten.
Da könnte mn noch diskutieren, ob die logische Verknüfung ("and" im Beispiel) in die neue Zeile kommt.

[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ß)

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