Source Formatter, der folgendes kann gesucht

[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