Die "richtige" Sourcecode Formatierung?

[Mavarik]

Was hierbei richtig und falsch ist, muss jeder für sich selber entscheiden.

Fakt ist : Wenn Sourcecode "anders" formatiert ist - und da ist sicherlich jeder ein Gewohnheitstier - lässt er sich

1. schlechter lesen
2. langsamer lesen

Also werden Fehler übersehen oder schlechter gefunden.

Aber was ist mit den "neuen" Sprachfeatures gibt es dafür Regeln? An den Fehlern in der IDE (Auto-End-Einfügung) oder (Doppelte generische Verschachtelung) stellt man schnell fest... Die IDE kann damit auch nicht richtig umgehen.

Wenn man schon sehr lange programmiert ( und früher gab es noch keine Regel für Sourcecode ) hatten Proceduren gerne mal 1000 Zeilen oder mehr... Viel mehr.... Sehr viel mehr.... Was also, wenn die procedure nicht auf den Monitor passt (macht ja keiner mehr) was aber wenn? Und was ist, wenn dann um alles noch ein if muss...?

Delphi-Quellcode:

Procedure FooLang(Foo : integer);
begin
  if Foo > 77 then begin
  ....

Gib es einen ELSE-Teil? Keinen Plan, dann scroll mal runter... Also einfach eine Regel dafür:

IF Regel:

Delphi-Quellcode:

Procedure FooLang(Foo : integer);
begin
  if Foo > 77 then  // if hat kein else-Teil, then hinter IF
    begin
      ...
    end;

  if Foo > 77 
    then begin // if hat einen else-Teil und ich sehe das an der 1. Zeile...
           ...
         end
    else begin
           ... 
         end;

Was ist mit Classen Design:

So?

Delphi-Quellcode:

type
  TFoo = class
    private
      procedure Bla;
      function Blub : Integer;
      procedure Setwert(Value : Integer)
      function getwert : Integer
      procedure Settext(Value:String)
      function gettext:String
    public
      Property Wert:integer read getwert write setwert;
      property TestmessageValue:string read gettext write settext;
   end

oder doch lieber so:

Delphi-Quellcode:

type
  TFoo = class
    private
      Procedure Bla;
      Function. Blub : Integer;
      Procedure SetWert( AValue : Integer )
      Function. GetWert : Integer
      Procedure SetText( Const AValue : String )
      Function. GetText : String;
    public
      Property Wert............ : Integer read GetWert write SetWert;
      Property TestmessageValue : String. read GetText write SetText;
   end

Die Punkte sind nur, weil das Forum die Leerzeichen löscht...

Was ist mit anonymen Proceduren?

Delphi-Quellcode:

begin
  TAynFactory.Default.RegisterObj(Function : IFoo begin result := TFoo.Create; end);
end;

Mit Sicherheit nicht... oder?

Delphi-Quellcode:

begin // #1
  TAynFactory.Default.RegisterObj(
    Function : IFoo 
      begin 
        result := TFoo.Create; 
      end);
end;

Delphi-Quellcode:

begin // #2
  TAnyFactory.Default.RegisterObj(Function : IFoo 
    begin 
      result := TFoo.Create; 
    end);
end;

Delphi-Quellcode:

begin // #3
  TAnyFactory.Default.RegisterObj( Function : IFoo 
                                     begin 
                                       result := TFoo.Create; 
                                     end );
end;

Angefangen habe ich mit Variante #3, aber da ich mittleiweile ständig so arbeite, bin ich zu #2 über gegangen...

Was ist mit Fluiddesign?

Delphi-Quellcode:

begin // #1
  TFMXFluidCreator<TListBoxItem>.RegisterDefault(
     Procedure (LBI : TFMXFluidCreator<TListBoxItem>) 
       begin
         LBI.Style('listboxitembottomdetail').
         Height(49).
         ItemMore.
         OnClick(
         Procedure (Sender : TObject)
           var
             S : String;
           begin
             S := TListBoxItem(Sender).
                  Tag.
                  ToString; 
             TEventBus.
                DefaultBus.
                Publish(TBusMemoMessage.Create(S));
             Memo1.Lines.Add(S);
           end,false);
    end);
end

Delphi-Quellcode:

begin // #2
  TFMXFluidCreator<TListBoxItem>.RegisterDefault(Procedure (LBI : TFMXFluidCreator<TListBoxItem>) 
    begin
      LBI.Style('listboxitembottomdetail').Height(49).ItemMore.OnClick(Procedure (Sender : TObject)
           var
             S : String;
           begin
             S := TListBoxItem(Sender).Tag.ToString; 
             TEventBus.DefaultBus.Publish(TBusMemoMessage.Create(S));
             Memo1.Lines.Add(S);
           end,false);
    end);
end

Delphi-Quellcode:

begin // #3
  TFMXFluidCreator<TListBoxItem>.RegisterDefault(
    Procedure(LBI: TFMXFluidCreator<TListBoxItem>)
    begin
      LBI.Style('listboxitembottomdetail').Height(49).ItemMore.OnClick(
        Procedure(Sender: TObject)
        var
          S: String;
        begin
          S := TListBoxItem(Sender).Tag.ToString; // Das lasse ich so...
          TEventBus.DefaultBus.Publish(TBusMemoMessage.Create(S));
          Memo1.Lines.Add(S);
        end, false);
    end);
end

Delphi-Quellcode:

begin // #4
  TFMXFluidCreator<TListBoxItem>.RegisterDefault( Procedure ( LBI : TFMXFluidCreator<TListBoxItem >) 
    begin
      LBI.
      {} Style( 'listboxitembottomdetail' ).
      {} Height( 49 ).
      {} ItemMore.
      {} OnClick( Procedure ( Sender : TObject )
           var
             S : String;
           begin
             S := TListBoxItem( Sender ).Tag.ToString; // Das lasse ich so...
             TEventBus.DefaultBus.Publish( TBusMemoMessage.Create( S ) );
             Memo1.Lines.Add( S );
           end,false );
    end);
end

#1 & #2 kann doch keiner mehr lesen... oder?
#3 ist ein Autoformat
#4 ist auch ein Autoformat die {} verhindern ein zusammen ziehen der Fluid-Elemente. Mit der Procedure im OnClick( kann man sich dann wieder streiten... Aber da ich das "procedure" immer hinten lasse - mache ich es auch so...

Case...

Delphi-Quellcode:

begin // #1
  Case ch of
    'A' : Blub;
  end; { of case } // <- Immer, da eine der wenigen Stellen, wo es ein "end" ohne "begin" gibt.
end;

Delphi-Quellcode:

begin // #2
  Case SetType of
    csCool   : Blub;
    csUnCool : Foo
    else raise exception.Create('SetType nicht definiert'); // IMMER, vielleicht habe ich das Set geändert und die Case vergessen?
  end; // of case 
end;

Delphi-Quellcode:

begin // #3
{$REGION '  FDK CaseSelector'}
    case TFDKHelper.CaseSelector<String>(AFieldName,
      {0} ['Name',
      {1}  'Vorname',
      {2}  'Strasse',
      {3}  'PLZ',
      {4}  'ORT'],Function (A,B : String) : boolean
                    begin
                      Result := SameText(A,B);
                  end){$ENDREGION}
 {Case AFieldname } of
     0 : Result := 24;
     1 : Result := 22;
     2 : Result := 32;
     3 : Result := 5;
     4 : Result := 22
    else raise ESystemException.Create('CaseSelector Feldname nicht in Liste: Mavarik Anrufen');
  end; // of case
end;

Delphi-Quellcode:

begin // #4
//FDK CaseSelector  (hier als Kommentar weil das Forum es nicht anders kann)
 {Case AFieldname } of
     0 : Result := 24;
     1 : Result := 22;
     2 : Result := 32;
     3 : Result := 5;
     4 : Result := 22
    else raise ESystemException.Create('CaseSelector Feldname nicht in Liste: Mavarik Anrufen');
  end; // of case
end;

#1 & #2 sind meine festen Regeln...
#3 für Typen die eine Case nicht kann und das wird dann mit der Region wie #4 dargestellt... So kann man es lesen...

Soweit mein kleine Auszug...

Mavarik

[Der schöne Günther]

Nur falls wir noch die "Fachbegriffe" für die verschiedenen Konventionen suchen:

https://en.wikipedia.org/wiki/Indent_style#Styles

[mensch72]

Wir sind zwar hier in einem Pascalforum, aber ich komme von C/C++ was ich embedded immernoch zu 50% meiner Zeit programmiere.

Seit 20Jahren schreibe ich C/C++ so, auch wenn es wegen der mit eingerückten Blockklammern nicht dem StandardStyleGuide entspricht:

Code:

if(test()==value)
    {
    test_true();
    }

if(irgendwas()==value)
    {
    machwas_true();
    }
else
    {
    machwas_false();
    }

//und dann weiter mit irgendetwas

In C finde ich die zusätzlichen Zeilen mit nur einer Klammer gut, aber Pascal/Delphi mag ich wegen der oft eh etwas ausführlicheren Schreibweise das nicht und mache es einheitlich so:

Code:

if(test()=value) then begin
    test_true();
end;

if(irgendwas()=value) then begin
    machwas_wenn_true();
end else begin
    machwas_wenn_false();
end;

//und dann weiter mit irgendetwas

Ich bin der Meinung, solange man IMMER einheitlich innerhalb einer Sprache formatiert, kann jeder der es es "will" dies auch lesen und verstehen, StyleGuides hin oder her.
Innerhalb einer Funktion/Procedure muss die Formatierung einheitlich sein, aber ich kann in Quelltexten wo zig Leute einzelne Klassenmethoden ausprogrammieren sogar Vorteile sehen, wenn ich über die Formatierung erkenne, wer es gemacht hat.
Wir handhaben das sehr locker ohne großen Zwang, solange jede Formatierung zumindest in sich klar & logisch erklärbar ist&bleibt. Klar kann man auch bzgl. Formatierung was komentieren, aber bei uns hat es sich nicht durchgesetzt.
Das z.B. typische und aus meiner Sicht viel wichtigere Problem, ob man jede Funktion/Procedure mit nur "einem Result=" bzw. "einem Exit" ganz am Ende verlassen soll, oder ob es anfangs mehrere "If Blöcke" geben kann, welche jeweils direkt die Funktion/Procedure verlassen... wir bevorzugen die Variante mit mehreren Exits!... das ist einfach nachträglich besser erweiterbar, als ewig immer tiefere If(+Else) Schachtelungen... lieber 8 ausprogrammierte "IFs ohne Else", als 2^3 geschachtelte "if-then-else"!

Das sind bei uns so die "grundsätzlichen" Fragen... Anonyme Methoden verwenden wir nun auch, schreiben da aber möglichst nur einen Aufruf einer "woanders normal" geschriebenen Procedure hinein... das darf dann sogar mal in nur einer "inline" Zeile sein.

Ich schreibe grundsätzlich in Pascal/Delphi pragmatisch immernoch so, wie ich es schon immer auch in C/C++ ohne "lokale Funktionen/Proceduren" hätte schreiben müssen. Die Kollegen der reinen Delphi Fraktion haben mich deshalb bisher noch nicht gesteinigt

[bra]

Zitat von Mavarik:

oder doch lieber so:

Delphi-Quellcode:

type
  TFoo = class
    private
      Procedure Bla;
      Function. Blub : Integer;
      Procedure SetWert( AValue : Integer )
      Function. GetWert : Integer
      Procedure SetText( Const AValue : String )
      Function. GetText : String;
    public
      Property Wert............ : Integer read GetWert write SetWert;
      Property TestmessageValue : String. read GetText write SetText;
   end

Diese Formatierungen mit Einrückungen sind zwar ganz nett zu lesen, aber immer dann wenn man neue Funktionen oder Properties hinzufügt, die länger sind als das schon vorhandene, fängt man an, alles umzuformatieren und das ist einfach zeitaufreibend und nutzlos. Zumal einem die IDE bei sowas überhaupt nicht unterstützt.

Ich bin der Meinung, es gibt keine "richtige" Formatierung, auch weil jeder ein wenig anders tickt und den Quellcode anders erfasst. Ein Kollege macht im Quellcode z.B. keinerlei Leerzeichen und ich finde das immer grauenvoll zu lesen, er kommt damit prima klar.

[Sherlock]

Die IDE unterstützt bei so manchem. Aber das Ausrichten der Methodennamen hat sie halt noch nicht drauf.
Manchmal ist es zu viel des Guten, da wird so weit auseinandergezogen, daß man (ich ) sich in der Zeile vertun kann.

Zum Thema "richtige" Formatierung: Freilich bleibt es Einzelkämpfern überlassen, ihren Code nach Gutdünken zu formatieren. Sie können ihn auch mit rosa Blümchen tapezieren. Aber es gibt tatsächlich Formatierungsrichtlinen von Borland...Codegear...Embarcadero (in der Tat haben die sich seit mindestens 8 Jahren nicht verändert, Generics fehlen komplett und allgemeines Entstauben täte gut). Ein Team, in dem es bekanntlich keine Einzelkämpfer gibt, tut gut daran sich an diese Richtlinien zu halten. Es wird IMMER Diskussionen geben, gerade was das Ausrichten von Typnamen oder auch '=' in Konstanten betrifft. Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Sherlock

[uligerhardt]

Zitat von Sherlock:

Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Is klar, ne. Du kennst meine Kollegen nicht.

[Sherlock]

Zitat von uligerhardt:

Zitat von Sherlock:

Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Is klar, ne. Du kennst meine Kollegen nicht.

Das war mit Absicht sehr...einfach formuliert Ich hab ja schließlich auch diesen Kampf schon endlos ausgefochten. Selbst das Berufen auf "neutrale Dritte" hat nichts geholfen. Aber als Tipp, was wirklich hilft: Vor dem nächsten Commit einfach die komplette Unit formatieren lassen. Das ist dann nämlich ein weiterer Beweis für die normative Kraft des Faktischen

Sherlock

[uligerhardt]

Zitat von Sherlock:

Aber als Tipp, was wirklich hilft: Vor dem nächsten Commit einfach die komplette Unit formatieren lassen. Das ist dann nämlich ein weiterer Beweis für die normative Kraft des Faktischen

Das wird dann im Zweifelsfall schon wieder "korrigiert".

[Uwe Raabe]

Zitat von Sherlock:

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

Der Vorteil dieses Styles ist einfach, daß sich auch die mitgelieferten Sourcen in der Regel daran orientieren - so wie viele andere Projekte auch. Man fühlt sich dort dann einfach wie zuhause. Jede davon abweichende Regel müsste schon eine sehr gute Begründung mitbringen, die deutlich über ein das ist mein persönlicher Geschmack oder das mache ich schon immer so hinaus geht. Und wenn schon jeder Standard besser ist als kein Standard, dann ist dieser Standard immerhin auch nicht schlechter als jeder andere Standard.

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.

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.

[uligerhardt]

Zitat von Uwe Raabe:

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.