Source Formatter, der folgendes kann gesucht

[Lemmy]

Zitat von RSE:

@Furtbichler:
Ich halte die Auslagerung von Quelltext in eigene Funktionen für kein geeignetes Mittel zur Strukturierung.

Du nicht, aber viele die sich mit Qualität von Sourcecode auseinander setzen schon.

Wenn ich versuche deinen Code oben zu verstehen, dann muss ich erst mal deine IF-Bedingungen KOMPLETT durchkauen und verstehen. Steht dagegen ein Funktionsaufruf, der einen korrekten Namen hat (d.h. der Name sagt wirklich das aus um was es geht), dann verstehe ich den Sinn innerhalb kürzester Zeit, weil die Komplexität der Bedingung erst mal vor mir verborgen wird. Wenn mich dann die Funktion interessiert habe ich zwar immer noch mit der komplexen Bedingung zu tun, aber dann halt NUR noch mit der Bedingung und nicht mehr mit dem was anschließend kommt.


Grüße

[Sir Rufo]

Und wenn schon anders formatiert, dann doch bitte so:

Delphi-Quellcode:

if 
  ( MyIntegerVarWithVeryExtendedTooLongName = 
    MyOtherIntegerVarWithVeryExtendedTooLongName )
and
  ( SomeOtherVar > SomeIntegerVar ) 
and
  (
    ( IntVar > IntConst1 ) 
  or
    ( IntVar > IntConst2 ) 
  or
    ( IntVar > IntConst3 ) 
  or
    ( IntVar > IntConst4 )
  ) 
then
  AnweisungMitSehrLangemNamen( 
    ArgumentMitSehrLangemNamen, 
    ZweitesArgument );

Das müsste man einem Formatierer sogar beibringen können

[Bummi]

@Sir Rufo

[RSE]

Also der bei Delphi XE eingebaute Formatierer kann diese Umbrüche so nicht herstellen. Da bleibt alles ziemlich durcheinander. Er kann im besten Fall so etwas draus machen:

Delphi-Quellcode:

  if ((i > 5) and (i < 15) and (i < 15) and
      ((i < 15) and (i < 15) and
        (i < 15))) and
    (i < 15) and (i < 15) and (i < 15) and (i < 15) and
    (i < 15) and (i < 15) and (i < 15) then
    ShowMessage('');

Wo umgebrochen wird, ist dabei allerdings schon handgemacht. Der Delphi XE Formatter würde bei automatischen Umbruch nur dort umbrechen, wo die Zeile zu lang ist. Das sieht dann so aus:

Delphi-Quellcode:

  if ((i > 5) and (i < 15) and (i < 15) and ((i < 15) and (i < 15) and (i < 15))
    ) and (i < 15) and (i < 15) and (i < 15) and (i < 15) and (i < 15) and
    (i < 15) and (i < 15) then
    ShowMessage('');

Man beachte die "Klammer auf" am Zeilenanfang! Außerdem muss ich mir bei diesen beiden Möglichkeiten Mühe geben zu erkennen, wo der Kopf der Struktur aufhört und der Rumpf anfängt, geschweige denn im zweiten Fall die Klammerung zu überblicken.

Alternativ könnte man das "then" immer in eine neue Zeile packen:

Delphi-Quellcode:

  if ((i > 5) and (i < 15) and (i < 15) and ((i < 15) and (i < 15) and (i < 15))
    ) and (i < 15) and (i < 15) and (i < 15) and (i < 15) and (i < 15) and
    (i < 15) and (i < 15)
  then
    ShowMessage('');
  if (i > 5)
  then
    ShowMessage('');

Bei mehrzeiligen Bedingungen hat das durchaus Vorteile, aber bei kurzen/einzeiligen Bedingungen sieht es einfach nur ... aus.

Ich möchte mich auch ungern Ewigkeiten mit diesem Thema befassen. Aus diesem Grund habe ich diesem Thread gestartet, um nicht der Reihe nach Formatierer durchprobieren zu müssen.

[Namenloser]

@Furtbichler: Achtung, auch eigene Meinung: Für jede Unter-Abfrage eine Funktion zu deklarieren, mag sich in der Theorie gut anhören, aber in der Praxis finde ich es oft nicht sinnvoll. Denn jede Funktion erzeugt wieder zusätzlichen Code (function (); begin end; usw.), und wenn man viele Trivial-Funktionen hat, wo der eigentliche Code nur aus 1–2 Zeilen besteht, wird der Code schnell unnötig aufgebläht. Sprechende Funktionsnamen zu haben, ist sicher gut für die Verständlichkeit, aber ständig zwischen verschiedenen Stellen im Code hin- und herspringen zu müssen, ist auf der anderen Seite ein großer Nachteil. Gut, vielleicht kommt mancher damit besser klar... ich persönlich habe lieber möglichst den gesamten Code der Abfrage gleichzeitig im Blick. Ich habe auch kein Problem damit, eine mehrzeilige if-Abfrage geistig zu parsen.

Und Kommentare gibt es ja zum Glück auch noch. Ich bin damit zwar normalerweise eher zurückhaltend (weil sie eben auch wieder dazu führen, dass der Code aufgebläht wird), aber in solchen Fällen setze ich sie gerne ein, weil sie immer noch weniger Platz brauchen als eine Funktionsdeklaration, und der Code an Ort und Stelle bleibt, wo er hingehört.

Als Faustregel kann man sagen, dass ich Code nur dann in eine Funktion auslagere, wenn sie an anderen Stellen auch noch mal gebraucht wird.

[RSE]

@NamenLozer
Du sprichst mir aus der Seele.

[Sir Rufo]

Ein SourceCodeFormatter hat ja die einzige Daseinsberechtigung darin, den SourceCode leserlicher zu machen. Und ab hier fängt es an Geschmackssache zu werden, wer was wie formatiert haben möchte, damit es für einen selber leserlicher wird.

Unter der Vorgabe der Strukturierung finde ich meinen Vorschlag allerdings gar nicht so daneben, weil durch die Formatierung die Struktur sichtbar wird.

Die Leerzeichen erhöhen mE die Lesbarkeit (bei Quelltexten), denn anders als bei einem normalen Text, wo man die Klammern nur am Rande wahrnimmt und die Wörter auch beim schnellen Drüberfliegen vom Gehirn zusammengesetzt werden, gelten bei einem SourceCode andere Regeln.

Bei einem Text ist es egal, ob ich die eine oder andere Klammer nicht so direkt wahrnehme, oder ein Wort mal falsch gedeutet habe, denn durch den Kontext kann man das in vielen Fällen wieder korrigieren, ohne die Stelle erneut lesen zu müssen.

Bei einem SourceCode gelten diese Regeln nicht, denn der Kontext kann durch einen Klammer mehr oder weniger völlig verändert werden, genauso wie ein überlesener Buchstabe.

Am Ende ist und bleibt es aber immer ein individuelles Thema, denn wenn der Styleguide etwas vorschreibt wodurch die eigene Arbeitsgeschwindigkeit sinkt und der individuelle Style die Arbeitsgeschwindigkeit hebt, dann kann sich der Styleguide mal selber gerne haben

[Furtbichler]

Als Einleitung: Jeder programmiert so, wie er will und so, wie seine Teamkollegen es zulassen (so er denn welche hat).

Zitat von NamenLozer:

...erzeugt wieder zusätzlichen Code..

In 99.9% aller Fälle ist Performance kein Thema, denn es kommt in erster Linie auf das Verfahren an. Die restlichen 0.1%, also die performancekritischen Programmteile, werden entweder mit 'inline' refaktorisiert oder aber explizit komplex aber dafür notwendigerweise performant implementiert und entsprechend kommentiert.

Das Ausbleiben von Refaktorisierung sollte jedoch immer die Ausnahme sein, nie die Regel.

Zitat:

...aber ständig zwischen verschiedenen Stellen im Code hin- und herspringen zu müssen...

Gerade das musst Du eben nicht machen, denn wenn dort z.B. steht:
If CountryIsInEuroZone(myCountry) then ist es für das Verständnis des eigentlichen Codes irrelevant, wie die Funktion umgesetzt ist. Und wer denn die Implementierung sehen will, für den bieten moderne IDE im Übrigen über Tastaturkürzel diese Möglichkeit (Delphi scheint irgendwie nicht dazu zu gehören).

Zitat:

...ich persönlich habe lieber möglichst den gesamten Code der Abfrage gleichzeitig im Blick. Ich habe auch kein Problem damit, eine mehrzeilige if-Abfrage geistig zu parsen.

Ich unterstelle Dir mal, das Du weder professionell, noch produktiv oder im Team programmierst. Denn dein Kollege würde dich für deine Ignoranz hassen. Desweiteren bezweifle ich, das Du nach 6 Monaten noch weisst, was mit dem mehrzeiligen Ausdruck gemeint ist. Mir ist die Zeit im Übrigen zu schade, um das 'im geiste zu parsen'.

Auch wenn das folgende Argument an die 100 Mio nicht irrenden Fliegen erinnert: Überlege mal, weshalb Refaktorisierungstools so beliebt sind.

Zitat:

Und Kommentare gibt es ja zum Glück auch noch.

Die weitaus meisten Kommentare sind böse, lügen, werden nicht gepflegt oder gar nicht erst angelegt. Du bist ja ein Beispiel dafür, da Du keinen Kommentar für solchen Code benötigst (Du schaffst es ja, ihn geistig zu parsen. Ich übrigens auch, habe aber keine Lust darauf).

Zitat:

Als Faustregel kann man sagen, dass ich Code nur dann in eine Funktion auslagere, wenn sie an anderen Stellen auch noch mal gebraucht wird.

Yo, DRY eben. Mach das mal präventiv: "Ich schreib ne allgemeingültige Funktion dafür. Wer weiss, vielleicht kann ich sie mal gebrauchen" und schon bist Du deinem Ziel, guten Code zu schreiben, ein Stück näher.

Ich stelle immer wieder fest, das gute Programmierer durch die selben Phasen der Codeformatierung und Implementierung gehen:
-Erste Gehversuche und verzweifelte Suche nach Syntaxfehlern.
-Sichere Beherschung der Syntax, Selbstüberschätzung weil Programme auch mal funktionieren.
-Entdecken des DRY-Prinzips und Verfechter des All-In-One-Codes.
-Erste größere nachhaltige Projekte und Verzweiflung beim Pflegen des Codes.
-Kommentierung von Code, damit man ihn nach einem Jahr noch versteht.
-Verringerung der Codekomplexität, weil die Einsicht entsteht, das Einfachheit (kurze Methoden), Lesbarkeit, Wartbarkeit und Robustheit untrennbar miteinander verbunden sind.
-Weitere Vereinfachung des Codes.
-Noch mehr Vereinfachungen.
...

Die Frage ist doch: Wo stehst Du und wo willst Du hin?

Zitat von Bummi:

um dagegenzuhalten, genialer Code kann so formatiert werden dass er komplett unleserlich wird.

Ich glaube, genialer Code ist immer lesbar. Weil er einfach ist. Wäre er kompliziert, wäre er nicht genial, sondern würde höchstens das Problem lösen.

Zitat:

Aber wir geraten OT.

Hast Recht. Aber wieso nicht?

[Edit] Ich habe gerade ein nettes Zitat gefunden:

Zitat von Nick Hodges:

Remember, the future maintainer is the person you should be writing code for, not the compiler.

[RSE]

Ihr habt alle irgendwie Recht. Die Realität liegt irgendwo zwischen all diesen theoretischen Betrachtungen. Nicht jede mehrzeilige Bedingung lässt sich sinnig in einem oder zwei Worten ausdrücken (abgesehen von sowas wie BedingungFuerIFAnDerStelleXY) oder gar an (potenziell) anderer Stelle wiederverwenden. Auch für diese Fälle möchte ich unsere Regeln umsetzen. Ich bitte daher darum wieder zum Thema zurückzukehren. Wenn jemand einen Formatter kennt, der meine Bedingungen befriedigt, bitte ich um Nennung. Die Bedingungen sind:

• Standardeinrückung nach Umbruch wegen zu langer Zeile: 2 Leerzeichen (kann der eingebaute Formatter von Delphi XE)
• Ausrichtung der Einrückung nach Umbruch wegen zu langer Zeile bei Kontrollstrukturen an der Bedingung (also bei IF 3 Leerzeichen - kann der eingebaute Formatter von Delphi XE nicht)
• Zusätzliche Einrückung bei noch offenen Klammern um 1 Leerzeichen pro offener Klammer (notfalls 2 Leerzeichen, ist besser als keins - der eingebaute Formatter von Delphi XE kann nur zusätzliche Standardeinrückung, also 2 Zeichen)

[Namenloser]

Ich hoffe du verzeihst mir noch eine kleine Richtigstellung:

Zitat von Furtbichler:

Zitat von NamenLozer:

...erzeugt wieder zusätzlichen Code..

In 99.9% aller Fälle ist Performance kein Thema, denn es kommt in erster Linie auf das Verfahren an. Die restlichen 0.1%, also die performancekritischen Programmteile, werden entweder mit 'inline' refaktorisiert oder aber explizit komplex aber dafür notwendigerweise performant implementiert und entsprechend kommentiert.

Ich redete vom Source-Code, nicht vom generierten Maschinencode. Um die Performance des Programms mache ich mir eher keine Sorgen, nur um die Performance des Programmierers