Die "richtige" Sourcecode Formatierung?

[Lemmy]

Zitat von jaenicke:

Wegen des begin in einer Zeile:
Ich empfinde es als unsauber, wenn mehrere Befehle in eine Zeile gequetscht werden. Da läuft man nur in Gefahr etwas zu überlesen.

Grundsätzlich sehe ich das wie Du: Wenn die IDE eine Formatierung als Standard verwendet mit der ich klar komme - warum ändern.. da bin ich viel zu faul dafür


Ich habe aber einige Jahre das Begin hinter die if-Verzweigung gesetzt (natürlich auch bei anderen Anweisungen), musste aber feststellen, dass diese Konstellation div. Probleme verursacht, wenn bei der Wartung nicht aufgepasst wird (d.h. das sind Fehler die vermutlich mir, aber auch anderen Entwicklern im Team passiert sind):

Anweisungen stehen im Block (eingerückt), aber das Begin-End fehlt - d.h. nur die erste Anweisung nach if wurde ausgeführt, die anderen immer
Anweisungen stehen nicht im Block (eingerückt) aber mit Begin-end (sollten also nicht im Then-Zweig stehen, tun sie aber)

...

All das hat mich dazu bewogen, das begin und end konsequent zu schreiben, auch bei nur einer Anweisung - auch um das Hirn bei der "Mustererkennung" zu entlasten

[-=ZGD=-]

Zitat von Lemmy:

All das hat mich dazu bewogen, das begin und end konsequent zu schreiben, auch bei nur einer Anweisung - auch um das Hirn bei der "Mustererkennung" zu entlasten

Sehe ich genauso. Hierbei geht es weniger um Faulheit, als um Wartbarkeit. Begin-End müssen einfach sein.

[Mavarik]

Zitat von Lemmy:

um das Hirn bei der "Mustererkennung" zu entlasten

Das ist für mich der absolut wichtigste Punkt...

Eine Code-Zeile wir i.d.R.

1x geschrieben
10x gelesen

Also ist ganz klar, ich muss mich entlasten...
Das geht natürlich über die Formatierung hinaus... Dafür braucht es Regeln (Ganz alleine für mich)

Argumente haben ein A-davor...

Also

Delphi-Quellcode:

Procedure (Const AValue : String);
begin
end;

Setter haben immer eine AValue egal von welchen typen.
Array Getter und Setter haben immer INDEX <- auch in Capslock geschrieben damit es auffällt.

Type immer ein T
Interfaces immer ein I
Lokale Variablen immer ein L... (Außer unsere geliebte For-Schleifen-Variable (i) )
Früher hatten Records immer ein Typ dahinter Datum : DatumsTyp; Zeit : ZeitTyp; (Aus UCSD-Pascal Zeiten)

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Generische Parameter heißen Arg1 Arg2 Arg3
Generische Record Bestandteile heißen Item1, Item2, Item3
Generische Typen heißen <T> oder es wird die Funktionalität bezeichnet <TResult>, <TArg>, <TSource>, <TDestination>

usw...

vor und nach einem " := " kommt eine Leertaste
Das letzte end; <- hat auch ein ";" auch wenn es nicht gebraucht wird.

Von Oliver übernommen

"( Parameter : Integer )" vor und nach den () von Parametern eine Leertaste.
"{}" Als Augenpunkt: Hier geht es weiter und damit der Autoformatter die Zeile nicht ändert.


Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Ich könnte noch ewig so weiter machen - stelle ich gerade fest...

Mavarik

[Stevie]

Zitat von Mavarik:

Bei einer Zeile

Wert := Werte;

Was ist da Werte?

Wert := Werte(); // Klar
Wert := IWerte; // Klar;
Wert := AValue; // Auch klar

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.
Da man normalerweise seine Elemente vernünftig benennt (und ich meine nicht mit nem Prefix, obs ein Parameter, lokale Variable oder sonst was ist, sondern das, was dieses Element an Daten enthält), ergibt sich die Frage, ob ich eine Funktion aufrufe oder aus einer lokalen Variable oder einem Parameter den Wert hole, beim Lesen nicht.

Zitat von Mavarik:

Dann noch die praktischen Sachen..

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
  ,Unit2
  ;

Einfacher um mal eben eine Unit mit // aus zu schalten...

Bei dieser Formatierung frage ich mich immer, was daran nun einfacher auszuschalten ist, als bei:

Delphi-Quellcode:

uses
  System.SysUtils,
  Unit1,
  Unit2;

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte (ok, wenn nun in Unit1 oder Unit2 Symbole aus SysUtils verdeckt werden, dann hat man bei einer Umordnung natürlich gelitten, aber wer macht sowas schon ).

[Mavarik]

Zitat von Stevie:

Bei dieser Argumentation, die ich schon oft gesehen habe, frage ich mich immer:
Welche Information bringt es mir, zu sehen, von welcher Art der rechte Ausdruck ist - imo ist diese Information unnötig und in der Regel nicht notwendig.

Ganz einfach...

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Delphi-Quellcode:

begin
  TTask.Run(Procedure
    begin
      Wert := Werte(); // Zugriff auf VCL???
    end;
end;

Muss ich nachsehen, ob darin nicht etwas steht wie:

Delphi-Quellcode:

Function Werte : Integer;
begin
  Caption := 'Wert geholt';
  Result := 42;
end;

Zitat von Stevie:

Bei deiner kannst du SysUtils nicht einfach rausnehmen, da dann das Komma vor Unit1 stört, bei meiner nicht Unit2, da dann das Semikolon fehlt. In beiden Fällen gibt es eine Zeile, die nicht funktioniert. Und in beiden Fällen kann man die Units ein einer solchen Reihenfolge schreiben, dass die problematische Zeile eine ist, die man in den meisten Fällen nicht auskommentieren möchte

Na warum soll ich auch Sysutils raus nehmen... Das steht doch mit Sicherheit da, weil es gebraucht wird..
Wenn ich also eine Liste habe kann ich einfach "meine" Units raus nehmen...

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
  ,Unit1
//  ,Unit2
  ;

Delphi-Quellcode:

Uses
  System.SysUtils
//  ,Unit1
//  ,Unit2
  ;

Klasse oder?

Mavarik

[Stevie]

Zitat von Mavarik:

1. Ich weiß sofort worum es geht ohne zu scrollen...
2. Wenn ich einen Funktionsaufruf sehe... Ist es eben keine einfache Zuweisung... Bedeutet bei einem Refactoring nach:

Nonsense Code gewinnt imo keinen Punkt bei dieser Argumentation, weil:
1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht
2. Funktion macht mehr als eine Sache (was wiederum dazu verleitet ihr einen prägnanten/unaussagekräftigen Namen zu geben)

Zitat von Mavarik:

Klasse oder?

Wie erwähnt, dann stell ich bei mir eine Unit nach unten, die ich aller Wahrscheinlichkeit nach nicht herausnehme, und habe dasselbe erreicht.

[p80286]

Das mit den Units, mache ich genauso wie Mavarik, wobei man bei der ersten Unit natürlich gekniffen ist.
Man kann halt nicht alles haben.

Zitat von Stevie:

1. unpassender Name, der nämlich genau dazu führt, dass ich nachschauen muss, was sie macht -> sowieso schlecht

Dann gehörst du aber zu sehr glücklichen Menschen, die gleich bei der ersten Eingabe direkt wissen, was der treffende Name ist. Ich brache immer 2 ode drei Überarbeitungen, bis alles so ist, daß ich auch in einem Jahr noch verstehe wie der Code funktioniert.

Gruß
K-H

[Stevie]

Zitat von p80286:

Dann gehörst du aber zu sehr glücklichen Menschen, die gleich bei der ersten Eingabe direkt wissen, was der treffende Name ist. Ich brache immer 2 ode drei Überarbeitungen, bis alles so ist, daß ich auch in einem Jahr noch verstehe wie der Code funktioniert.

Nö, bestimmt nicht, ich verbringe einen großen Teil meiner Zeit damit, meinen eigenen (gestern natürlich noch von mir selbst fälschlicherweise als perfekt bewerteten ) oder fremden Code zu refactorn

[Neutral General]

Zitat von p80286:

Das mit den Units, mache ich genauso wie Mavarik, wobei man bei der ersten Unit natürlich gekniffen ist.

Wenns bei einer Unit eh nicht funktioniert, dann kann man in meinen Augen auch so machen wie Stevie.
Das sieht visuell zumindest ordentlicher aus in meinen Augen. So ein Komma als Anfang der Zeile vor einem Wort sieht komisch aus.