UnitOptimizer

[stahli]

Das habe ich mir ganz alleine ausgedacht (glaube ich).
Ich finde es bei der Codevervollständigung sinnvoll, gleich zu sehen, dass man einen Getter oder Setter vor sich hat.

Es ist aber auch hier kein Problem, eine Option für verschiedene Schreibweisen einzurichten (und auch eine Checkbox für "erzwingen", so dass vorhandene Getter und Setter entsprechend umbenannt werden).

Also das würde ich mal nicht als Problem sehen wollen, höchstens als Geschmacksverirrung.

[stahli]

Ich habe von hsg mal zwei Units mit einigen Herausforderungen bekommen .
Da sind halt schon einige Stile drin, die ich so nicht kenne. Jetzt will ich dem Optimizer beibringen, damit umzugehen und die Unit u.a. neu zu sortieren, ohne das Styling dabei zu zerschießen...

Hier dazu mal ein neuer Zwischenstand.

Um z.B. Beschreibungen über Methoden diesen zuzuordnen, müssen sie als "echte Kommentare" gekennzeichnet werden.
Dann werden sie zur Methode zugehörig interpretiert und mit verschoben (der Optimizer passt ja regelmäßig die Reihenfolgen der Methoden an).

Im Gegensatz dazu sieht man unten, dass "Auskommentierungen" wie Code behandelt werden. Wenn "auskommentierter Code" über einer Metho steht, wird er dieser also nicht zugeordnet und würde entsprechend nicht mit der Methode umsortiert.

Wenn man die Funktionalität des Optimizers nutzen möchte, muss man also Kommentare immer passend auszeichnen.

Echte Kommentare werden mit ":" oder "!" eingeleitet, wobei ':' noch in den Codefluss eingerückt wird und bei "!" keine automatische Anpassung erfolgt (hier also der Programmierer komplett selbst das Aussehen bestimmt).

Ich denke, mit dieser Anforderung (echte Kommentare besonders zu kennzeichnen) sollte man leben können. Nur so kann der Optimizer diese unterschiedlich behandeln.

[stahli]

Hallo zusammen,

hier eine neue Testversion als Exe.
Links kann Code per C&P eingefügt werden und rechts erhält man wieder das formatierte Ergebnis.

Es sollten einige Verbesserungen zur ersten Version erkennbar sein, aber es kann natürlich noch Probleme geben.

Hier ein paar kurze Videos:

a) Allgemeines: https://youtu.be/jhB7eb4ci3Y
Der aktuelle Stand und einige Optionen.

b) Kommentarvarianten: https://youtu.be/zyiBAZMBQQA
Der Optimizer unterscheidet zwischen echten Komentaren (formatiert und unformatiert) und auskommentiertem Quelltext.
Wenn man den Optimizer nutzen möchte, sollte man unbedingt darauf achten, echte Kommentare entsprechend zu kennzeichnen.
Für den Compiler macht das dann keinen Unterschied aber für die Codedarstellung und Optimierung ist eine Unterscheidung wichtig.

c) spezielle Einrückungen: https://youtu.be/KdRK1-Yl5LQ
Der Optimizer unterstützt "Tabs", um bestimmte Codestellen untereinander auszurichten.
Beispielsweise werden Getter und Setter in Propertydeklarationen untereinander ausgerichtet.
Hier stellen sich eini9ge Detailfragen, wenn lange Bezeichner verwendet werden und Zeilen umgebrochen werden müssen.
Welche Regeln bzw. Optionen würdet Ihr diesbezüglich für sinnvoll halten?
Ähnliche Fragen ergeben sich bezüglich Fluent Interfaces. Was würdet Ihr das für sinnvolle Optionen halten?

d) Test-Runs: https://youtu.be/GyybXwaCKpk
Das ist eher etwas für mich und für Profis.
Man kann erfolgreich optimierte Units abspeichern und bei neueren Programmversionen testen, ob das als positiv festgestellte Ergebnis dann weiterhin erzielt wird.
Es ist etwas Bastelarbeit und erfordert ein externes Vergleichstool (z.B. Beyond Compare).
Wer den Optimizer einsetzen will und sicherstellen möchtem dass erzielte Optimierungen auch künftig noch erzielt werden, kann sich so einige Units ablegen um künftige Prüfungen durchführen zu können - im Sinne eriner Qualitätssicherung.
Grundsätzlich ist das jedoch eine Funktion für Entwickler des Tools.

e) Planung: https://youtu.be/w3973h1G0IE
Geplant ist ein kommerzielles Angebot und eine kostenfreie Version, jeweils als Formatierer zur Einbindung in Delphi.
Bis das bei mir stabil funktioniert werde ich aber aucvh gern weitere Versionen als externe Exe zur Verfügung stellen.

Ich würde mich über Rückinfos freuen, was Ihr vom derzeitigen Stand und den weiteren Aussichten haltet...

[stahli]

Sorry, da waren doch noch ein paar Fehler drin.
Ich hatte die Ergebnisse nur optisch geprüft und nicht beachtet, dass ich zuvor mit einem falschen Stand weiter gearbeitet hatte.

Also anbei eine aktualisierte Exe.

Ich habe jetzt auch schon zumindest 2 echte Units innerhalb Delphi formatieren lassen (Ctrl-Shift-O anstatt Ctrl-D), was wunderbar funktioniert hat.
Compilieren kann ich die Units wie zuvor und das Styling ist weitestgehend wie erhofft, aber im Detail muss ich mir das nochmal ansehen (bin allerdings ziemlich platt nach Durcharbeiten am Wochenende ).

Ich stelle Euch auch gern mal ein Package zur Einbindung als Delphi-Experten zur Verfügung, bin aber nicht sicher, was man dazu (ohne Quelltext) weiter geben muss.
Anbei mal eine Zip. Ich bin aber nicht sicher, ob die reicht (kompiliert für D 10.3.2. CE).

Natürlich solltet Ihr das Tool noch vorsichtig einsetzen.
Die Änderungen lassen sich mit Ctrl-Z rückgängig machen, aber es ist natürlich auch möglich, dass das Tool mal abstürzt oder sich aufhängt. Ist halt noch eine frühe Phase!
Ich werde es jetzt jedenfalls selbst regelmäßig benutzen und ständig verbessern...

Wenn jemand Interesse oder Tipps hat, dann gebt bescheid...

[stahli]

noch ein neuer Stand...
Es ist jetzt soweit, dass es schon ganz gut real einsetzbar ist.

Der ganze Komplex der Codevervollständigung fehlt noch.
Was jetzt enthalten ist, wird etwa die kostenfreie Codeformatierung sein (+/- einige Features).

Hat jemand das Tool mal als Experten eingebunden und getestet?

Jetzt werden Bookmarks und Breakpoints erhalten und ggf. mit dem Quelltext zusammen verschoben (auch später, wenn mal ganze Codeteile verschoben werden).

Das Zusammenklappen der erzeugten Getter&Setter-Regionen funktioniert noch unzuverlässig.
Das System habe ich noch nicht richtig verstanden. Hat da jemand Erfahrung und kann helfen?

Bin gespannt...

[stahli]

Hmm...

Also die Widerherstellung der Bookmarks und Breakpoints nach der Codeformatierung habe ich im Griff.
Auch das Zuklappen der "Getter+Setter"-Regionen funktioniert.

Allerdings sind die ToolsAPI aus meiner Sicht nicht sehr eingängig.

Eigentlich würde ich aber nach dem Formatieren schon gern die Regionen wieder so auf- und zugeklappt herstellen, wie sie vor der Formatierung waren.

Die besten Infos zum Thema habe ich hier gefunden:
https://parnassus.co/mysteries-ide-p...ed-elided-code
Allerdings übersteigt das meine Fähigkeiten und ist mir zu heikel, so etwas zu realisieren.

Weiß jemand evtl, wie die IDE die Informationen über auf- und zugeklappte Regionen speichert und diese wieder herstellt?

Wenn es keine machbare Lösung gibt, kann ich auch mit meiner bisherigen Lösung leben.
Eine komplette Wiederherstellung des vorherigen Standes wäre mir aber schon noch lieber.

[dummzeuch]

Ich habe in GExperts (insbesondere im Code-Formatter) mit Code-Folding / Unfolding herumexperimentiert, es aber irgend wann aufgegeben. Es ist den Aufwand einfach nicht wert (zumindest für mich persönlich).

Das Verschieben der Bookmarks und Breakpoints ist auch ziemlich aufwändig. Ich habe es einigermaßen hinbekommen, aber perfekt ist es definitiv nicht. Wenn das bei Dir besser klappt: Hut ab!

Die Einstellungen zum Code Folding werden anscheinend in der .dsk-Datei des Projekts gespeichert, und zwar im Eintrag "Elisions" des jeweiligen Views:

Code:

[View0]
CustomEditViewType=TEditView
Module=D:\source\test\Unit1.pas
CursorX=1
CursorY=9
TopLine=1
LeftCol=1
Elisions={{10,23},{15,6},{''}}
Bookmarks=
EditViewName=D:\source\test\Unit1.pas

Ob Dir das allerdings hilft, ist fraglich, denn die Datei wird anscheinend erst beim Schließen des Projekts aktualisiert.

[stahli]

Danke.

Ich könnte mir vorstellen, das Speichern und Laden der Regionen-Zustände nachzubauen und um den Aufbereitungsprozess zu setzen.

Aber es gibt da offenbar so viele unterschiedliche Module und Daten, die da zusammenspielen, dass das ziemlich unsicher wäre, alles stabil zu händeln.
Wenn es eine übersichtliche Zusammenfassung gäbe oder die Quelltexte einsehbar wären, würde ich das mal versuchen. So ist das aber wohl zu unübersichtlich. Haben andere offenbar auch schon so eingeschätzt.

Worauf basiert die Delphi-IDE eigentlich? Anscheinend gibt es da eine gemeinsame Basis zu Visual Studio und anderen Editoren. Jedenfalls landet man mit Suchbegriffen aus den ToolsAPI auch öfter bei MS und in anderen Bereichen.

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

Hallo,

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

Stichwort "Regionen".

Das zweite Bild ist echt grausam anzusehen.