Die "richtige" Sourcecode Formatierung?

[uligerhardt]

Zitat:

Zitat von Uwe Raabe (Beitrag 1344458)

Was mir noch fehlt ist eine Mäglichkeit, die automatische Formatierung für eine Zeile oder einen Bereich ausser Kraft zu setzen. Es gibt halt immer mal wieder Ausnahmen.

Wir benutzen nach wie vor den GExperts-Formatter, da kann man das mit speziellen Kommentaren erreichen.

[BUG]

Zitat:

Zitat von Uwe Raabe (Beitrag 1344458)

In der Regel steht bei mir der integrierte Formatter auch auf diesen (Default-)Einstellungen. Lediglich die Zeilenlänge setze ich passend zu den heute üblichen Widescreens auf einen höheren Wert. Durch die Kommandozeilenversion lassen sich auch problemlos ältere und fremde Sourcen ohne großen Aufwand anpassen.

Die wichtigste Regel für Style-Guides: Wähle einen Style-Guide, den du mit einem vorhandenem Formatter durchsetzen kannst :mrgreen:

Zitat:

Zitat von uligerhardt (Beitrag 1344460)

Aber als Tipp, was wirklich hilft: Vor dem nächsten Commit einfach die komplette Unit formatieren lassen.

Aber bitte in einem extra Commit! Sonst sieht man im Diff nicht mehr, ob/wo etwas interessantes geändert wurde.

[bra]

Zitat:

Zitat von Sherlock (Beitrag 1344449)

Aber es gibt tatsächlich Formatierungsrichtlinen von Borland...Codegear...Embarcadero

Ich halte mich sogar (unbewusst) weitestgehend an die, außer das mit dem begin nach if/while usw. mache ich anders ;)

[Neutral General]

Zitat:

Zitat von bra (Beitrag 1344465)

Zitat:

Zitat von Sherlock (Beitrag 1344449)

Aber es gibt tatsächlich Formatierungsrichtlinen von Borland...Codegear...Embarcadero

Ich halte mich sogar (unbewusst) weitestgehend an die, außer das mit dem begin nach if/while usw. mache ich anders ;)

Ich kann die Logik hinter dieser Formatierung nicht verstehen. Nach dem offiziellen Style sind begin/end auf einer Ebene, Man sieht sofort welches begin zu welchem end gehört.
Welchen Vorteil soll es haben das begin hinter das then zu schreiben?

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1344466)

Ich kann die Logik hinter dieser Formatierung nicht verstehen. Nach dem offiziellen Style sind begin/end auf einer Ebene, Man sieht sofort welches begin zu welchem end gehört.
Welchen Vorteil soll es haben das begin hinter das then zu schreiben?

Meiner Meinung nach ergibt sich das aus dem Textfluß
entweder

Delphi-Quellcode:

if Bedingung then machwas;

oder

Delphi-Quellcode:

if Bedingung then begin
  machwas;
  machmehr;
end;

Wenn das begin in die nächste Zeile rutscht, sieht das so eigenständig aus und mir fehlt da der Bezug zum if.
Das fällt besonders auf wenn kein Syntaxhighlighting aktiv ist.


Gruß
K-H

[bra]

Zitat:

Zitat von Neutral General (Beitrag 1344466)

Ich kann die Logik hinter dieser Formatierung nicht verstehen. Nach dem offiziellen Style sind begin/end auf einer Ebene, Man sieht sofort welches begin zu welchem end gehört.
Welchen Vorteil soll es haben das begin hinter das then zu schreiben?

Ich finde es einfach nur schrecklich unübersichtlich sowas hier zu schreiben, weil hier die else-Teile in dem end/begin total untergehen und man auch wieder nicht sieht, zu welchem begin das end jetzt wieder gehört.

Delphi-Quellcode:

if .. then
begin
  ..
end
else if .. then
begin
  ..
end
else
begin
  ..
end;

Für mich ist das übersichtlicher und genauso logisch, da das if/else und das zugehörige end auf einer Höhe sind.

Delphi-Quellcode:

if .. then begin
  ..
end
else if .. then begin
  ..
end
else begin
  ..
end;

Unter C/Java ist meine Schreibweise sogar die empfohlene (dort halt mit Klammern).

[bcvs]

Zitat:

Zitat von bra (Beitrag 1344474)

Delphi-Quellcode:

if .. then begin
  ..
end
else if .. then begin
  ..
end
else begin
  ..
end;

Dem kann ich mich nur anschießen. Ich schreibe es genau so. Außerdem ist für mich das Argument mit der eingesparten Zeile nach wie vor nicht von der Hand zu weisen. Gerade in längeren Blöcken mit vielen Elsen kommt da einiges zusammen.

[Mavarik]

Zitat:

Zitat von bcvs (Beitrag 1344479)

Außerdem ist für mich das Argument mit der eingesparten Zeile nach wie vor nicht von der Hand zu weisen. Gerade in längeren Blöcken mit vielen Elsen kommt da einiges zusammen.

Zeilen einsparen? Wofür?

Es wird Dir zu lang... Mach ne procedure draus...

Quelltext ohne Leerzeile kann ich gar nicht lesen...

Vor und nach jedem if/while/for/repeat kommt auf jeden Fall eine Leerzeile. Es sei den es steht ein Begin davor...

Genauso gibt es niemals zwei Anweisung oder Zuweisung in einer Zeile.

Funktionen die keinen Parameter haben werden mit Foo(); geschrieben... Damit ich sofort sehe, dass es keine Variable ist, sondern ein Call...

Sir Rufo hat da noch eine ganz besondere Konstruktion für If's mit langen and und or Teilen, die auch die Lesbarkeit verbessert...

Delphi-Quellcode:

procedure TForm1.SpeedButton1Click( Sender: TObject );
var
  lRateThisApp: IFDKRateThisAppService;
begin 
  if true
  {} and TPlatformServices.Current.SupportsPlatformService( IFDKRateThisAppService, lRateThisApp )
  {} and lRateThisApp.ShowRateDialogIfNeeded( )
  then
    Log( 'Dialog angezeigt' );
end;

Einfach die Bedingungen bei allen {} durch gehen und schon ist klar worum es geht...

Mavarik :coder:

[Jumpy]

Zitat:

Zitat von bra (Beitrag 1344474)

Ich finde es einfach nur schrecklich unübersichtlich sowas hier zu schreiben, weil hier die else-Teile in dem end/begin total untergehen und man auch wieder nicht sieht, zu welchem begin das end jetzt wieder gehört.

Delphi-Quellcode:

if .. then
begin
  ..
end
else if .. then
begin
  ..
end
else
begin
  ..
end;

Dafür gibt es aber doch das Einrücken, so wie das Beispiel ist würde man das doch nicht machen.
Mit Einrücken wird dann doch klar welches begin/end zusammen gehört.

Delphi-Quellcode:

if .. then
  begin
  ..
  end
else if .. then
  begin
  ..
  end
else
  begin
  ..
  end;

[Neutral General]

Zitat:

Zitat von Jumpy (Beitrag 1344504)

Dafür gibt es aber doch das Einrücken, so wie das Beispiel ist würde man das doch nicht machen.
Mit Einrücken wird dann doch klar welches begin/end zusammen gehört.

Das find ich mindestens genauso schlimm wie das begin hinter das then zu schreiben. Vielleicht sogar ein Stück schlimmer :duck: