UnitOptimizer

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

Anbei mal eine zweite Testversion.
Ich habe noch einiges ergänzt, aber es ist noch nicht fertig.

Richtigen Kommentar sollte man unbedingt auch so kennzeichnen damit er nicht als auskommentierter Code interpretiert wird.
Vor allem, wenn er über einer Methode steht und dieser zuzuordnen ist.

Das kann dann so aussehen:

Delphi-Quellcode:

//: Text
{: Text :}
(*: Text :*)

Das ist aber das Einzige, das man beachten muss.


Im Moment macht noch Probleme, wenn Schlüsselwörter wie uses, var, const, begin usw. nicht allein in einer Zeile stehen.
Daran arbeite ich dann als nächstes.


@hsg
Schau mal, das sollte jetzt schon besser aussehen. :-)

[jaenicke]

Bei Verwendung von etwas umfangreicheren Generics stürzt das Tool schlicht ab bzw. hängt mit voller Prozessorkernauslastung.

Dort kommen Konstrukte wie dieses vor (ob es daran liegt weiß ich nicht):

Delphi-Quellcode:

    class procedure RegisterStatusData<T, I: ICustomDataEntry; C: class, constructor, ICustomDataEntry; K: ICustomDataList<T>>;
...
class procedure TApplicationInterface.RegisterStatusData<T, I, C, K>;
begin
  RegisterInterfaceProvider<T>(
    function...
...

Die Unit kann ich leider nicht veröffentlichen, da sie Firmeneigentum ist.

// EDIT:
Jetzt bin ich etwas erstaunt. Die Ursache ist ein eigentlich absolut simpler Codeteil. Interessanterweise klappt es sobald ich eine der drei Propertys entferne. Der Code dürfte doch keinen Parser vor irgendwelche Probleme stellen...

Delphi-Quellcode:

unit Common.Core.ApplicationInterface;

interface

type
  TApplicationInterface = class
  public
    class property InterfaceProvider: IInterfaceProvider read GetInterfaceProvider;
    class property DummyProvider: IInterfaceProvider read GetDummyProvider;
    class property CurrentProvider: IInterfaceProvider read GetCurrentProvider;
  end;

implementation

end;

(Es ist egal, ob die Methodendeklarationen und -rümpfe dabei sind oder nicht.)

[hoika]

Hallo,
zumindestens fehlt ein uses für IInterfaceProvider.

[jaenicke]

Das habe ich alles herausgeworfen, im Original lässt sich die Unit natürlich kompilieren. Ich glaube auch nicht, dass das eine Rolle spielt, denn sonst müsste man ja angeben können wo diese Units liegen usw., zumal es dem Parser egal sein sollte. Die Verknüpfungen werden ja auf höherer Ebene erstellt.

[TigerLilly]

Zitat:

Zitat von stahli (Beitrag 1449622)

Richtigen Kommentar sollte man unbedingt auch so kennzeichnen damit er nicht als auskommentierter Code interpretiert wird.
Vor allem, wenn er über einer Methode steht und dieser zuzuordnen ist.

Das kann dann so aussehen:

Delphi-Quellcode:

//: Text
{: Text :}
(*: Text :*)

Das finde ich problematisch, weil es schon einige Konventionen für Kommentar gint. MMX hat //1 und //2, PasDoc hat auch ein paar Konventionen. Wäre es nicht besser, den kommentierten Code extra zu kennzeichnen? Oder das konfigurierbar zu machen?

[stahli]

Ich danke Euch.


@jaenicke

class var, methodes und properties sowie anonyme Methoden werden noch nicht unterstützt.

Ich schaue mir das aber mal als nächsten Punkt an.
Kann wieder ein paar Tage dauern. Ab morgen muss ich wieder arbeiten... :-/


@TigerLilly

Optional könnte man das erwägen.
Allerdings nutzt man Ctrl-# ja meist, um mal eine Zeile oder Abschnitt schnell "raus zu schmeißen". Da wäre es umständlich, noch etwas an der Standardformatierung ändern zu müssen.

Dagegen ist es seltener (zumindest für mich), dass man erläuternden Kommentar schreibt.
Da man dort ohnehin etwas neues schreibt, kann man dort auch ein zusätzliches Zeichen einfügen.

Aber da kann man nochmal die sinnvollste Lösung abstimmen.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1449648)

Das finde ich problematisch, weil es schon einige Konventionen für Kommentar gint. MMX hat //1 und //2, PasDoc hat auch ein paar Konventionen. Wäre es nicht besser, den kommentierten Code extra zu kennzeichnen? Oder das konfigurierbar zu machen?

Insbesondere XMLDOC gibt hier schon von Delphi-Seite einen Standard vor: Kommentare in der XML-Dokumentation

[stahli]

Das habe ich schon dabei.

Der Kommentar wird mit dem Code bündig eingerückt und mehrere Leerzeichen nacheinander werden auf eins verkürzt.
Könnte ich noch ändern, falls nötig.

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