Source Formatter, der folgendes kann gesucht

[RSE]

Hallo,

ich möchte gern einen Source Formatter einsetzen. Der in Delphi XE mitgelieferte hat allerdings keine weiteren Optionen zur Einrückung bei (weil länger 80 Zeichen) umgebrochenen Zeilen. Ich möchte, dass folgender Quellcode zumindest so bleibt, wenn der Formatter drübergeht:

Delphi-Quellcode:

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

Genauer gesagt steht in unserem Styleguide u.a. folgendes:

• Wird die Bedingung im Kopf einer Kontrollstruktur umgebrochen, so richtet sich die Einrückung der nächsten Zeile am Beginn der Bedingung aus
• Die Einrückung kann vergrößert werden, um die Lesbarkeit der Klammerung zu verbessern

Die Einrückung im Kopf einer IF-Struktur (nicht IF-Schleife) ist daher standardmäßig 3, ggf. plus Einrückung je nach Klammerung.

Gibt es Source Formatter, die so etwas zulassen können? Oder bei denen man das sogar als Formatierung so einstellen kann?

Edit: IF ist nun keine Schleife mehr. ;-)

[generic]

Damit man dich nicht hänselt zum Thema IF-Schleife:
Es gibt eine Internetwebseite, welche alles wichtige dazu zusammen fasst!
http://if-schleife.de/

[RSE]

Ich gebe dir allumfassend Recht! Wie ist der korrekte Oberbegriff für if, case, while, repeat, try etc.?

[DeddyH]

Kontrollstrukturen sollte es ganz gut treffen.

[RSE]

OK, damit wäre das geklärt. Zurück zur Frage im 1. Post ;-)

[Furtbichler]

Der Formatierer für diese Art von Code sitzt vor dem Rechner und muss nur Refactoring anwenden. Schreibe deinen Code einfach so, das er auf eine Zeile passt, wobei 'Zeile' durchaus 100-140 Zeichen umfassen darf.

Was ich damit sagen will: Gottseidank gibt es keine Formatierer, die grottenschlecht lesbaren Code so formatieren, das er ein wenig weniger grottenschlecht lesbar ist.

Wenn Du z.B. so eine komplexe Abfrage hast, dann packe sie in eine Funktion und nenn das Kind beim Namen.

Delphi-Quellcode:

if DieBedingungenSindAlleErfuellt then
  AnweisungMitSehrLangemNamen(ArgumentMitSehrLangemNamen,
    ZweitesArgument);

Aber ich merke gerade, das deine Frage eine ganz andere war :oops: (egal oben gesagtes musste ich einfach mal wieder loswerden).

Ich verwende DelForExp und dort gibt es die Markierungen '{(*}' und '{*)}' um Codestellen, die nicht formatiert werden sollen, so zu belassen. Das Teil kommt z.B. nicht mit 'class var' und Record-Methoden klar und dafür verwende ich es.

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

Zitat von RSE (Beitrag 1174886)

@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 :stupid:

[Bummi]

@Sir Rufo

:thumb:

[Furtbichler]

Achtung! Eigene! Meinung!

Zitat:

Zitat von Sir Rufo (Beitrag 1174895)

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

:kotz:

Zitat:

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

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 (

Delphi-Quellcode:

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:

Zitat von NamenLozer (Beitrag 1174948)

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

Delphi-Quellcode:

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:

Zitat von Bummi (Beitrag 1174972)

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:

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:

Zitat von Furtbichler (Beitrag 1174995)

Zitat:

Zitat von NamenLozer (Beitrag 1174948)

...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 ;)