UnitOptimizer

[stahli]

Hallo,

was haltet Ihr von einer Kennzeichnung der Klassen und ggf. Klassensektionen im Implementationsteil?

Die Klassendeklarationen werden entsprechend geordnet und in verschiedene Sektionen aufgeteilt.
Später erfolgen auch noch Unterteilungen nach eingebundenen Interfaces (z.B. "public //: IMyIntf" für die Properties und "protected //: IMyIntf" für die Getter und Setter).
Das macht der Optimizer alles automatisch und ist m.E. sehr übersichtlich.


Im Implementationsteil bin ich mir jedoch nicht so ganz sicher. Die Klassen so auffällig auszuzeichnen finde ich schon sinnvoll.
Aber bei den Sektionen sollten vielleicht nur die Interface-Sektionen explizit ausgezeichnet werden?
Sollte die Sortierung dann dort vielleicht sogar abweichend zur Interface-Deklaration sein?
Ich kann natürlich auch wieder mehrere Optionen anbieten.
Was würdet Ihr bevorzugen?


PS: Das standardmäßige "{ TMyClass }" der Delphi-IDE könnte automatisch umgewandelt werden. Das wäre technisch kein Problem.

[DasWolf]

Zitat:

Zitat von stahli (Beitrag 1461468)

Hallo,

was haltet Ihr von einer Kennzeichnung der Klassen und ggf. Klassensektionen im Implementationsteil?

Stichwort "Regionen".

Das zweite Bild ist echt grausam anzusehen.

[stahli]

Bei Zugriffrechten in Klassen wird von Abschnitten gesprochen. Daher hatte ich von Sektionen gesprochen.

Oder meinst Du, ich solle Regionen vorsehen, die man zuklappen kann?
Das fände ich unpraktisch, da man sich dann immer einen Wolf klappen müsste. ;-)


Optisch fand ich das auch im ersten Moment sehr hässlich. ABER:
Inzwischen finde ich das gar nicht so schlecht. Man hat quasi unmittelbar die Struktur der Klassendeklaration nochmal im Implementationsteil abgebildet und weiß ständig, wo man sich genau (auch mit welchen Zugriffsrechten) befindet.
Wenn man z.B. eine neue Prozedur in so einem gekennzeichneten Bereich schreibt, dann kann der Optimizer diese auch im passenden Bereich der Deklaration erzeugen. (Das könnte sogar bis in eine Interfacedeklaration weiter gereicht werden wenn man sich in einem "Interface-Abschnitt" befindet - ggf. auch erst nach Rückfrage).

Ich finde es inzwischen gar nicht mehr so sinnvoll, einen riesigen Implementationsteil mit jeder Menge Klassenimplementationen zu haben. Aber ist halt nun mal so Delphi, da kann man nix dran ändern.
Nun geht es darum, diesen Teil möglichst strukturiert zu gestalten (bzw. automatisiert gestalten zu lassen).

Man kann zwar das Codebeispiel optisch unschön finden, es aber dennoch (wie ich) für praktisch halten...

Oder man kann dem gar nichts abgewinnen oder man findet das sogar stylisch!?.
Fest gemeißelt ist ja noch gar nichts. Daher wollte ich gern Meinungen und Vorschläge einholen.
Vielleicht kristallisieren sich ja ein paar machbare und sinnvolle Varianten heraus...?

[stahli]

Mal eine neue Test-Exe.
Jetzt erkennt man die Verschiebungen der Blöcke, was ggf. die Übersichtlichkeit erhöht (wenn man die Änderungen einmal genauer nachvollziehen möchte).

Jetzt werde ich mich endlich mit der Klassenvervollständigung befassen können. :-)

[stahli]

Optimierung der Umbrüche bei mehreren Tabs in einer Zeile.
Jetzt werden alle gleichartigen Tabs eines Blockes identisch umgebrochen (im Beispiel alle "write" der zusammengehörigen Properties - auch wenn nur eines nicht auf eine Zeile passt).

[stahli]

Testversion5 - einige kleine Problemchen bereinigt

[stahli]

Hier mal einige Screenshots einiger neuer Formatierungen.

Die ersten 3 zeigen Ausrichtungen und Umbrüche an "Tabulatoren".
Getter und Setter werden z.B. auch untereinander ausgerichtet, wenn sie (vorläufig) auskommentiert sind. Wenn sie später gelöscht werden bleiben dort entsprechend Lücken bestehen.
Umbrüche z.B. von längeren Konstanten werden am "=" ausgerichtet.

Dann einige Beispiele von Ausrichtungen von ":=".
Das war ein Wunsch eines Testers und ich fand die Idee eigentlich fragwürdig - also habe nicht mit einem guten Ergebnis gerechnet.

Aber das gefällt mir jetzt RICHTIG GUT! :-)

Ich werde das also so oder so ähnlich selbst nutzen und als Option mit einbauen.
Mich würde mal interessieren, was Ihr dazu sagt...

(Dass vor begin, else usw. bzw. nach then keine Zeilenumbrüche existieren, soll hier mal nicht das Thema sein. Die Einrückungen wären dann natürlich entsprechend auch wie abgebildet möglich.)

[stahli]

Ich habe mal eine Einrückung von Fluent-Interfaces umgesetzt: https://youtu.be/EKxBDecttOU (5 Min).

Sagt mir doch mal bitte, was Ihr davon haltet (insbesondere @Mavarik).

Nutzt das jemand und haltet Ihr die Umsetzung für tauglich?


EDIT: Das Einrücken unterhalb von Punkten habe ich doch noch realisiert (zwei neue Screenshots).
Es kann natürlich Fälle geben, in denen die Einrückung zu weit nach rechts reicht... !?
... Dann geht aber auch der Umbruch am ersten Punkt (Bild3).

[stifflersmom]

Daumen hoch, mir gefallen die Formatierungen schon sehr gut.
Respekt!

[HeZa]

Hallo Stahli,

das sieht hübsch aus.

Ich würde so allerdings niemals formatieren.

Ändert man z.B. den Klassennamen der Klasse mit dem Fluentinterface, würden sich unter Umständen sehr viele Units ändern wenn man diese Art der Formatierung konsequent anwendet.

Das sieht in der Versionsverwaltung immer schlecht aus (zum Glück kann wenigstens BeyondCompare Whitespace-Unterschiede ausblenden).

Bei ausgerichteten Zuweisungen, muss man für das Suchen aller Zuweisungen einer Variablen schon mit RegEx arbeiten.

Bei mir wird alles mit zwei Leerzeichen eingerückt und Zuweisungen (:=) haben immer ein Leerzeichen hinter dem Variablennamen. Habe ich mir nach dem Lesen von CodeComplete vor ..., boah, sind das echt schon Jahrzehnte, angewöhnt.

Ciao HeZa