Source Formatter, der folgendes kann gesucht

[RSE]

Kommentare zur Steuerung des Formatters lehne ich ab. Das möchte bitte alles so einstellbar sein, dass ich so etwas nicht brauche!

@Furtbichler:
Ich halte die Auslagerung von Quelltext in eigene Funktionen für kein geeignetes Mittel zur Strukturierung. Das führt lediglich dazu, dass ich ständig am Springen bin, wenn ich versuche später diesen Quelltext nachzuvollziehen und komplett zu verstehen (z.B. bei der Fehlersuche). Außerdem entstehen so unnötige Funktionsaufrufe. Und um dem gleich vorzubeugen: Ja, ich weiß von der inline-Möglichkeit und es macht bei den heutigen Prozessoren keinen großen Unterschied - außer es handelt sich um zeitkritische Routinen. Das vorher genannte reicht mir aber als Grund dagegen.

Eine Folge von Anweisungen sollte m.E. genau dann in eine Funktion ausgelagert werden, wenn sie an mehreren Stellen benötigt wird, also um Codedopplung zu vermeiden.

Sicherlich ist das auch Geschmackssache. Hier in der Firma sind wir allerdings alle der beschriebenen Meinung.

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

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

[Furtbichler]

Achtung! Eigene! Meinung!

Zitat von Sir Rufo:

Und wenn schon anders formatiert, dann doch bitte so:
..

Zitat:

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

Hoffentlich nicht.

Aber da ich das -wupps- mit meinem Formatierer wieder so hinbekomme, das ich nicht (aber dafür vermutlich Du) kotzen muss, ist das gehüpft wie gesprungen. Und wenn Du deinem Formatierer das so beibringt, das dein Schreibtisch sauber bleibt, können wir bedenkenlos Code austauschen (wenn wir wollten).

Ich bin entschiedener Gegner (und verteidige dies wie den stehenden Sack Reis) von Leerzeichen innerhalb der Klammern. Das macht man doch in der deutschen Sprache auch nicht (
oder
( doch )
oder
( wie ? )
)

Der Hauptgrund, weshalb ich das ablehnen würde, wäre aber der, das mein Formatierer das so nicht hinbekommt. Ich schere mich mittlerweile einen feuchten Kericht darum, wie formatiert wird. Nur DAS der Code formatiert ist, ist relevant. Im Team werden Einstellungen für den Formatierer vereinbart und dann verteilt. Nach ein paar Tagen hat sich auch der mit dem schwächsten Magen (also ich) an diesen Standard gewöhnt.

Die Zeit kann man wirklich mit sinnvolleren Dingen verbringen. Z.B. mit Refaktorisierung komplexer bool'scher Ausdrücke und Verbesserung der Lesbarkeit.

@Lemmy: Auf den Punkt gebracht.