Source Formatter, der folgendes kann gesucht

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

[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

[shmia]

Man darf aber durchaus boolsche Zwischenvariablen verwenden; die sind nicht so "schwergewichtig" wie Funktionsaufrufe.
Hier ein kleines konstruiertes Beispiel.

Delphi-Quellcode:

var
  erwachsen, HasAMobile : boolean;
begin
  erwachsen := (Person.Age >= 18);
  HasAMobile := StrIsOneOf(Person.Phone.Vorwahl, ['170', '172', ...]) and (Person.Phone.CountryPrefix = 49);

  if erwachsen and HasAMobile and (Person.Gender='W') then
    ShowMessage('Frau über 18 mit Handy');

Auf diese Weise kann man komplexe If-Bedinungen entschärfen und lesbarer machen.
Mit dem Debugger kann man schön die einzelnen Teilbedingungen anschauen!!

Was nützt es denn, wenn man eine If-Bedingung mit 10 komplexen Teilbedingung
scheinbar supergut formatiert aber man findet den Logikfehler nicht weil man
die vielen Einzelbedingung nicht komplett versteht (oder vor lauter Bäumen den Wald nicht sieht) .

Und bitte sag' jetzt niemand die paar Taktzyklen für die Zwischenvariablen würde sich an der Geschwindigkeit bemerkbar machen.

[shmia]

Häufig sieht man ja Code wie diesen:

Delphi-Quellcode:

if (land='DE') or (land='AT') or (land='IT') or (land='FR') or
  (land='ES') // Und so weiter
then
  ShowMessageFmt('Land %s gehört zur EU', [land]);

Und weil 27 Bedingungen so unübersichtlich sind wird angefangen jede Bedingung in eine eigene Zeile zu stellen:

Delphi-Quellcode:

if (land='DE') or 
  (land='AT') or 
  (land='IT') or // Und so weiter
then

Aber das macht es auch nicht besser.
Dabei kann man es ganz elegant schreiben:

Delphi-Quellcode:

var
  IsEuroZone : Boolean;
begin
  IsEuroZone := StrIsOneOf(land, ['DE','AT','IT','FR' ... ]);
  if not IsEuroZone then
    ShowMessageFmt('Land %s gehört NICHT zur EU', [land]);

[himitsu]

Oder das delphieigene MatchStr.

Nja, sagen wir es kurz und knapp:
Grauenhafter Code wird nicht gleich besser, nur weil man ihn schön formatiert. (mit Blümchen und rosa Shleifchen)

[Bummi]

um dagegenzuhalten, genialer Code kann so formatiert werden dass er komplett unleserlich wird.
Aber wir geraten OT.

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