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 :coder:

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

Zitat von Mavarik (Beitrag 1344409)

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 :D) 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:

Zitat von Sherlock (Beitrag 1344449)

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

Is klar, ne. :mrgreen: Du kennst meine Kollegen nicht.

[Delphi-Laie]

Zitat:

Zitat von Mavarik (Beitrag 1344409)

Was ist mit anonymen Proceduren?

Delphi-Quellcode:

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

Mit Sicherheit nicht... oder?

Oder was?

Was spricht gegen diese Zeile? Kann man doch "in eins" lesen?! Ich schreibe solche Funktions-/Prozedur-/Methodendeklarationen/-köpfe immer in eine(r) Zeile.

Ich würde noch begin und end entfernen, weil redundant.

[Sherlock]

Zitat:

Zitat von uligerhardt (Beitrag 1344454)

Zitat:

Zitat von Sherlock (Beitrag 1344449)

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

Is klar, ne. :mrgreen: Du kennst meine Kollegen nicht.

Das war mit Absicht sehr...einfach formuliert :D 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 8-)

Sherlock

[Uwe Raabe]

Zitat:

Zitat von Sherlock (Beitrag 1344449)

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:

Zitat von Sherlock (Beitrag 1344457)

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 8-)

Das wird dann im Zweifelsfall schon wieder "korrigiert". :?

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

[Mavarik]

Zitat:

Zitat von Jumpy (Beitrag 1344504)

Delphi-Quellcode:

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

Gruselig...Codesumpf nenne ich das...

Delphi-Quellcode:

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

Und schon is klar was wohin gehört...

ggf.

Delphi-Quellcode:

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

So würde ich es machen...

Mavarik :coder:

[mensch72]

Delphi-Quellcode:

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

... mache ich bzgl. Struktur genauso, nur etwas kompakter und nicht so "raumgreifend" in die Breite;)

Delphi-Quellcode:

if (..) then begin
  ..
end else begin
  if (..) then begin
    ..
  end else begin
    ..
  end;
end;

und zumindest in CNpack und auch aktuell integriertem Castalia sieht das sogar sehr sauber aus:)

[bernau]

Ich liebe solche Threads ;-)

Hier ist mein Beitrag zu den If then else

Delphi-Quellcode:

  
  If bla then
    TuWas;

  If bla then
    TuWas
  else
    TuWasAnderes;

  If bla then
    begin
      TuWas;
      TuNochWas;
    end
  else
    begin
      TuWasAnderes;
      TuNochWasAnderes;
    end;

  If bla then
    begin
      TuWas;
    end
  else
    If blabla then
      begin
        TuNochWas;
      end;

Eine Zeile, die mit "if" beginnt, hört immer mit "then" auf.

"Darunter" kommt die auszuführende Funktion. Natürlich eingerückt.

Das gilt auch für das Begin und End, die auf eine ebene gehören.

Bei verschachtelten Ifs finde ich, ist eine Einrückung des nächsten If zwingend notwendig, damit ich auf einen Blick sehe, dass es eine Verschachtelung ist.

[jfheins]

Zitat:

Zitat von Mavarik (Beitrag 1344516)

So würde ich es machen...

Mavarik :coder:

Schrecklich :stupid:

Ich würde das hier befürworten:

Delphi-Quellcode:

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

Sowas macht man ja eigentlich nur, wenn man eigentlich ein ein case-Konstrukt bräuchte, das aber nicht zugelassen ist. (Ausdruck zur Compilezeit variabel oder so...)
Insofern finde ich es sinnvoll, das auch optisch analog zu gestalten. Logisch ist das auch nur eine "Unterebene", da nur einer der Subblöcke ausgeführt wird.

Wenn man da jeden Subblock weiter einrückt, hat man ja schnell ewig lange Zeilen.

Zur Praxisrelevanz ein (delphisiertes) Codezitat:

Delphi-Quellcode:

startTime, endTime: string;

if (SpecificRegex.IsMatch(Event.Time)) then
begin
    match := SpecificRegex.Match(Event.Time);
    startTime := match[0];
    endTime := match[1];
end
else if (RegexA.IsMatch(Event.Time)) then
begin
    startTime := '8:00';
    endTime := '10:00';
end
else if (RegexB.IsMatch(Event.Time)) then
begin
    startTime := '9:00';
    endTime := '12:00';
end
else if (RegexC.IsMatch(Event.Time)) then
begin
    startTime := '12:00';
    endTime := '15:00';
end
else if (RegexD.IsMatch(Event.Time)) then
begin
    startTime := '14:00';
    endTime := '16:00';
end
else
begin
    allDayEvent := true;
    startTime := Event.startTimeDate;
    endTime := Event.EndDate.AddDays(1);
end

Da habe ich dann auch lieber deutliche Einrückungen (1 Tab = 4 Leerzeichen) damit man die Blöcke direkt sieht. Würde man dann allein für das begin eine eigene Einrückungsebene einziehen, vergeudet man ja die Hälfte des Platzes...
Ich würde daher aus

Delphi-Quellcode:

if bla then
  begin
    TuWas;
  end

das machen:

Delphi-Quellcode:

if bla then
begin
    TuWas;
end

Dann kann man auch (etwas leichter) links am Rand 'runtergucken um das nächste end zu sehen.

[bernau]

Auch wenn solche Threads sich wiederholen. Etwas kann man immer mitnehmen.

Durch solche Threads habe ich für mich das "Exit" entdeckt. Gibt's natürlich schon länger und habe ich bisher immer als "bah" angesehen. Beim näheren Hinsehen kann man das aber sehr sinnvoll als ersatz für die If-Verschachtelung verwenden.

Statt

Delphi-Quellcode:

  if bla then
    Result = 3
  else
    if blabla then
      Result = 5
    else
      if Blub then
        Result = 8
      else
        Result = 10

Finde ich folgendes besser lesbar

Delphi-Quellcode:

  if bla then
    Exit(3);
  if blabla then
    Exit(5);
  if Blub then
    Exit(8);
  Result = 10

[Mavarik]

Zitat:

Zitat von jfheins (Beitrag 1344521)

Sowas macht man ja eigentlich nur, wenn man eigentlich ein ein case-Konstrukt bräuchte, das aber nicht zugelassen ist.

nicht jede if then else ist ein Case ersatz!

Wo sind deine Then's geblieben? und auch noch Tabs... hmm ":="; hmm end : String?

Zitat:

Zitat von jfheins (Beitrag 1344521)

Da habe ich dann auch lieber deutliche Einrückungen (1 Tab = 4 Leerzeichen) damit man die Blöcke direkt sieht.

Immer 2 dann plötzlich 4??? Eher nicht.

Case Ersatz... (Wenn überhaupt)

Delphi-Quellcode:

start, end: string;

if (SpecificRegex.IsMatch(Event.Time))
  then begin
         match := SpecificRegex.Match(Event.Time);
         start := match[0];
         end   := match[1];
       end
  else 
if (RegexA.IsMatch(Event.Time))
  then begin
         start := '8:00';
         end   := '10:00';
       end
  else 
if (RegexB.IsMatch(Event.Time))
  then begin
         start := '9:00';
         end   := '12:00';
       end
  else 
if (RegexC.IsMatch(Event.Time))
  then begin
         start := '12:00';
         end   := '15:00';
       end
  else 
if (RegexD.IsMatch(Event.Time))
  then begin
         start := '14:00';
         end   := '16:00';
       end
  else begin
         allDayEvent = true;
         start = Event.StartDate;
         end = Event.EndDate.AddDays(1);
       end

[jfheins]

Zitat:

Zitat von Mavarik (Beitrag 1344523)

nicht jede if then else ist ein Case ersatz!

Nein, aber diese if then else -Ketten eher schon. Wenn da komplett unzusammenhängende Bedingungen abgefragt werden, dann würde ich da Leerzeilen einfügen zum trennen.

Zitat:

Wo sind deine Then's geblieben? und auch noch Tabs... hmm ":="; hmm end : String?

Immer 2 dann plötzlich 4??? Eher nicht.

Ups, länger nicht mehr Delphi gemacht. Thens habe ich nachgetragen, genauso wie die := :oops:
Sry, die Tabs werden im Forum nicht gut angezeigt. (Tabs vs Spaces würde ich auf später verschieben...) Ich habe sie durch Leerzeichen ersetzt ;-)

[Der schöne Günther]

Habt Ihr euch mal überlegt dass man im Endeffekt ganz andere Probleme hat wenn man anfangen muss 5-fach verschachtelte Bedingungen zu schreiben? :stupid:

Beiträge wie dieser sind wahrscheinlich der Grund weshalb ich nirgendwo eingeladen werde

[DeddyH]

Zitat:

Zitat von Der schöne Günther (Beitrag 1344525)

Habt Ihr euch mal überlegt dass man im Endeffekt ganz andere Probleme hat wenn man anfangen muss 5-fach verschachtelte Bedingungen zu schreiben? :stupid:

Beiträge wie dieser sind wahrscheinlich der Grund weshalb ich nirgendwo eingeladen werde

:thumb: (abgesehen davon finde ich den ganzen Thread irgendwie müßig, jeder hat da seine eigenen Vorlieben).

[bra]

Beim letzten Beispiel sieht man nur lauter IF's aber die so seltsam eingerückten ELSE vorher gehen komplett verloren. Das nenn ich mal unübersichtlich.

Ich denke über dieses Thema könnte man endlos streiten und nie zu einem Kompromiss finden, jeder hat hier halt seine Vorlieben. Vielleicht sollten wir es dabei auch belassen 8-)

[nahpets]

Ok, dann auch mal mein Senf dazu:

Delphi-Quellcode:

// Folgt auf ein If nur eine Anweisung, dann wird das ein Einzeiler, solange er nicht über ca. 80 Zeichen hinaus geht.
if ... then ...;
// Geht vorhergenanntes über ca. 80 Zeichen hinaus, dann wird es:
if ... then begin
  ...
end;
// Sind es mehr als eine Anweisung wird es analog dazu:
if ... then begin
  ...
  ...
end;

Das end ist immer genauso weit eingerückt, wie das dazugehörige if.
Folgen auf ein if mehrere Anweisungen, werden die eingerückt.
Durch die Einrückung erkenne ich, dass da was zusammen gehört. Das begin am Ende der If-Anweisung ist für mich daher eine Redundanz und hat keinerlei Informationswert für das Verstehen des Quelltextes. Daher brauchts dafür keine eigene Zeile und kann von mir aus auch rechts neben dem Bildschirm stehen ;-)
Das gilt analog auch für for, while, repeat ...

Wenn's um Alternativen beim if geht, sieht es so aus:

Delphi-Quellcode:

if  ...
and ...
and ... then begin
  ...
end else 
if ... then begin
  ...
  ...
end else 
if ...
or ... then
begin
  ...
end else
// Das sieht hier im Forum etwas anders aus, als im wirklichen Leben, da die Leerzeichen hier nicht die gleiche Breite haben, wie die Buchstaben und Zahlen und zum Teil "geklaut" werden.
// Schrifttyp im Quelltexteditor ist immer Courier New.
if  (x = y)
and (   (a = b)
     or (e = f)
    ) then begin
end;

Und da ich ein "alter Sack" bin, hab' ich schonmal was von der ungarischen Notation gehört. Da halte ich mich dran, soweit es verständlich ist. Dadurch brauche ich für die Unterscheidung von Funktionen und Variabeln auch kein Foo()-Konstrukt.

Variabeln fangen immer mit 'nem Kleinbuchstaben an, Funktionen und Prozeduren mit 'nem Großbuchstaben.
Besteht ein Funktions-/Prozedurname aus 'ner Beschreibung der Aufgabe, so beginnt in dem Namen jedes neue Wort mit 'nem Großbuchstaben. Z. B.: SeiteLaden, DatenSpeichern ...

Konstanten werden wie Variabeln benannt, bekommen aber noch ein c davor. z. B.: csConnectionString.
Damit weiß ich im Quelltext immer: das ist 'ne Konstante und zwar eine Zeichenfolge und sie enthalt die Verbindungszeichenfolge für 'ne Datenbankverbindung.
Resourcestrings beginnen mit rs.

Hab' ich z. B. eine Stringliste, die Referenzen aus einer HTML-Seite enthält, dann heißt sie slAHRef. Muss ich nun (was bei Stringlisten ja häufiger vorkommt) per For-Schleife darüber laufen, so bekommt die entsprechend Variabel den Namen iAHRef.

Sieht dann so aus (PascalScript, daher ein bisserl anders als Delphi):

Delphi-Quellcode:

function  SeiteLaden(sSeite : String) : Boolean;
var 
// Die Doppelpunkte stehen untereinander, 
// dadurch ist eine Sortierung im Editor nach Typ oder Name einfacher.
        slAHRef   : TStringList;
        slHTML    : TStringList;
        sUrl      : String;
        sMessage  : String;
        sTitel    : String;
        iAHref    : Integer;
        iIndex    : Integer;
        iID       : Integer;
begin
  Status(Format('Seite %s wird geladen ...', [sSeite]));
  iID    := qry.FieldByName('ID').AsInteger;
  AppTitle(Format('%d - %d',[iID,iMaxID]),'Textverwaltung');
  slAHRef := TStringList.Create;
  slHTML  := TStringList.Create;
  try
    sTitel := '<unbekannt>';
    sUrl   := Format('%s%s',[csRoot, sSeite]);
    Result := HTTPGet(sUrl, slHTML, slAHRef, sMessage, 5);
    ProcessMessages;
    if not Result then begin
      sUrl   := Format('%s%s%s',[csRoot, csPrograms, sSeite]);
      Result := HTTPGet(sUrl, slHTML, slAHRef, sMessage, 5);
      ProcessMessages;
    end;
    if Result then begin
      iIndex := slHTML.IndexOf('<title>');
      if (iIndex > 0) and (iIndex < slHTML.Count - 1) then sTitel := slHTML[iIndex + 1];
      if not qry.Locate('seite', sSeite, [loCaseInsensitive, loPartialKey]) then begin
        Inc(iMaxID);
        qry.Append;
        qry.FieldByName('ID').AsInteger          := iMaxID;
      end else begin
        qry.Edit;
      end;
      qry.FieldByName('Seite').AsString          := sSeite;
      qry.FieldByName('Titel').AsString          := sTitel;
      qry.FieldByName('Schluesselwort').AsString := sTitel;
      qry.FieldByName('Classname').AsString      := csAutor;
      qry.FieldByName('Parent').AsString         := csParent;
      qry.FieldByName('SeitenText').AsString     := slHTML.Text;
      qry.FieldByName('Teile').AsString          := '';
      try
        qry.Post;
      except
        AppLog('SeiteLaden (1)', Format('%s', [sSeite]));
        AppLog('SeiteLaden (1)', ExceptionParam);
        AppTitle(Format('Fehler bei Seite %s', [sSeite]), 'Textverwaltung');
        qry.Cancel;
      end;
      for iAHref := slAHRef.Count - 1 downto 0 do begin
        if (Pos(':', slAHRef[iAHref]) <> 0) then slAHRef.Delete(iAHref);
      end;
      for iAHref := slAHRef.Count - 1 downto 0 do begin
        if (Pos('../', slAHRef[iAHref]) = 1) then slAHRef[i] := AnsiReplaceText(slAHRef[iAHref], '../', '');
      end;
      for iAHref := slAHRef.Count - 1 downto 0 do begin
        if (Pos('.htm', slAHRef[iAHref]) = 0) then slAHRef.Delete(iAHref);
      end;
      for iAHref := slAHRef.Count - 1 downto 0 do begin
        iIndex := Pos('#', slAHRef[iAHref]);
        if iIndex > 0 then slAHRef[iAHref] := Copy(slAHRef[iAHref], 1, iIndex - 1);
      end;
      slAHRef.Sort;
      for iAHref := slAHRef.Count - 1 downto 1 do begin
        if slAHRef[iAHref] = slAHRef[iAHRef - 1] then slAHRef.Delete(iAHref);
      end;
      for iAHref := 0 to slAHRef.Count - 1 do begin
        if not qry.Locate('Seite',slAHRef[iAHref],[loCaseInsensitive]) then begin
          Inc(iMaxID);
          qry.Append;
          qry.FieldByName('ID').AsInteger            := iMaxID;
          qry.FieldByName('Seite').AsString          := slAHRef[iAHref];
          qry.FieldByName('Titel').AsString          := '';
          qry.FieldByName('Schluesselwort').AsString := '<neu>';
          qry.FieldByName('Classname').AsString      := csAutor;
          qry.FieldByName('Parent').AsString         := csParent;
          try
            qry.Post;
          except
            AppLog('SeiteLaden (2)',Format('%s',[slAHRef[iAHref]]));
            AppLog('SeiteLaden (2)',ExceptionParam);
            AppTitle(Format('Fehler bei Seite %s',[slAHRef[iAHref]]),'Textverwaltung');
            qry.Cancel;
          end;
        end;
      end;
    end else begin
      Applog('SeiteLaden (3)', Format('%s',[sUrl]));
      Applog('SeiteLaden (3)', Format('%s',[sMessage]));
    end;
  except
    Applog('SeiteLaden (4)', Format('%s - Titel: %d - %s', [sSeite,iIndex,sTitel]));
    Applog('SeiteLaden (4)', ExceptionParam);
  end;
  slRef.Free;
  slHTML.Free;
  qry.Locate('ID',iID,[loCaseInsensitive]);
end;

Und das schöne daran ist: Niemand, außer mir, muss damit zurecht kommen, das lesbar oder schön finden, und von daher ist das Ganze eigentlich vollkommen irrelevant.

Wenn ich in 'nem Team arbeite, dann halte ich mich natürlich an die dort vorgegebenen Richtlinien, egal wie sch... die Quelltexte auch aussehen mögen, behalte mir aber vor, Quelltexte anderer, die sich nicht daran halten bzw. Quelltexte die auf irgendeine andere Art und Weise unleserlich und/oder unübersichtlich sind, entsprechend den Richtlinien anzupassen (jedenfalls dann, wenn der Quelltext so konfus ist, dass (im Test oder in der Produktion) festgestellte Fehler im Quelltext "dank Unleserlichkeit" nicht gefunden werden können).

[mm1256]

Zitat:

Zitat von DeddyH (Beitrag 1344526)

:thumb: (abgesehen davon finde ich den ganzen Thread irgendwie müßig, jeder hat da seine eigenen Vorlieben).

Meine Worte im anderen Thread. :thumb: Aber, interessant mal zu sehen, wie Andere ihren Code formatieren.

[bernau]

Zitat:

Zitat von mm1256 (Beitrag 1344532)

Aber, interessant mal zu sehen, wie Andere ihren Code formatieren.

Darum geht es, deshalb finde ich solche Threads niemals müßig.

[jaenicke]

Für mich sind bei der Formatierung wichtig:

• Zwingend per Codeformatter machbar (nur manuell formatieren können ist Blödsinn, das dauert viel zu lange, wenn ich fremden Quelltext einpflegen muss usw.)
• Weite Verbreitung der Formatierung, keine Sonderlocken
• Natürliches Schreiben: keine tausend unnötige Leerzeichen oder ähnliches
• Ein Befehl pro Zeile (damit man nicht erst die ganze Zeile durchlesen muss um weiterzulesen)
• Pro logischer Ebene eine Einrückung um zwei Zeichen nach rechts
• Kein Plenken

Das macht die Standardformatierung bereits, deshalb gibt es für mich keinen Grund eine andere zu benutzen. Zumal dies die häufigste Formatierung ist, wenn man so Open Source usw. anschaut. Alles andere ist eher selten bis exotisch zu finden.

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.

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1344535)

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:

Zitat von Lemmy (Beitrag 1344543)

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.

[SProske]

Zitat:

Zitat von nahpets (Beitrag 1344530)

Delphi-Quellcode:

// Folgt auf ein If nur eine Anweisung, dann wird das ein Einzeiler, solange er nicht über ca. 80 Zeichen hinaus geht.
if ... then ...;

Und wenn du mal einen Haltepunkt auf die Anweisung setzen willst, ärgerst du dich über diese Anordnung und verteilst es wieder auf 2 Zeilen - richtig?

[Uwe Raabe]

Zitat:

Zitat von SProske (Beitrag 1344545)

Und wenn du mal einen Haltepunkt auf die Anweisung setzen willst, ärgerst du dich über diese Anordnung und verteilst es wieder auf 2 Zeilen - richtig?

Und deshalb bekommt der Befehl nach

Delphi-Quellcode:

then

eine eigene Zeile. Und weil man beim Zufügen weiterer Zeilen schnell mal das

Delphi-Quellcode:

begin

vergisst, werden auch solche Einzeiler in ein

Delphi-Quellcode:

begin-end

verpackt.

Aber auch hier gibt es wieder eine Ausnahme:

Delphi-Quellcode:

if ... then Exit;

bleibt auf einer Zeile, weil hier das Haltepunkt-Argument leider nicht zieht. Seitdem die IDE diese netten Flow-Icons anzeigt, ist das auch viel angenehmer und leichter zu lesen und lenkt nicht vom eigentlich relevanten Code ab.

[SProske]

Wieso sollte ich auf ein Exit keinen Haltepunkt setzen können/wollen?
Vielleicht interessiert es mich ja, ob das Exit während der Codeausführung überhaupt mal angesprungen wird (ohne bei jeder Prüfung anzuhalten).

[Jumpy]

Zitat:

Zitat von Mavarik (Beitrag 1344516)

Zitat:

Zitat von Jumpy (Beitrag 1344504)

Delphi-Quellcode:

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

Gruselig...Codesumpf nenne ich das...

Und ich nenne das nicht nett und aus dem Zusammenhang gegriffen.
Ist ja schön, wenn man mal sieht, wie andere den Code formatieren und warum. Das macht den Thread spassig. Wenn's aber zu "Mein Kung Fu ist besser als dein Kung Fu" abgleitet, bleibt der Spaß irgendwo auf der Strecke.

Ich habe so ein bißchen den Eindruck gewonnen, dass die Formatierung auch davon beeinflusst wird, in welchen Sprachen man noch so programmiert, sprich wie man in Java/C#/C++ die Klammern setzt, so setzt man begin/end in Delphi? Ich mache noch viel im Bereich MS-Office mit VBA. Da gibt es ja explizit das "ElseIf" und drum setzte ich das in Delphi halt auch in eine Zeile, weil der Code dann in Delphi ähnlich formatiert ist, wie in VBA.

Irgendwer hat auch geschrieben:

Zitat:

Delphi-Quellcode:

if ... then begin
  ...
end;

Das end gehört zum if ... (sinngemäß)

Ich dachte immer das end gehört zum begin (ausser beim try) und drum schreibe ich es auch auf eine Ebene.

Nur mal so nebenbei gefragt, macht ihr die Formatierungen bei Schleifen dann genauso?