UnitOptimizer

[stahli]

Danke an Euch alle.
Das hilft mir schon mal weiter.

@jaenicke
Ich habe das Beispiel gleich mal durchlaufen lassen.
Also die Standardfälle passen schon ganz gut. Nur der gesamte Else-Block wird noch nicht korrekt eingerückt. Das werde ich aber heute noch lösen können.
Das ist eben auch wieder so ein spachlicher Sonderfall. Else zum if ist etwas anders zu händeln als else zum case.
Ich konvertiere die Schlüsselwörter in Klassen mit bestimmten Eigenschaften. Bei Else im Kontext von Case werde ich wohl nur die Eigenschaft für die Einrückungsvorgaben ändern müssen.
Schaue ich mir heute Abend an.

Zitat von jaenicke:

Zitat von stahli:

Vor allem weiß ich natürlich auch nicht, welche Formatierungen (Einrückungen, mit oder ohne Umbrüche) da so im Umlauf sind und auf welche "Überraschungen" sich das Tool einstellen muss.

Das sollte dem Parser ja egal sein wie es vorher war.

Hier meinte ich eher die Wünsche und Anforderungen, welche Varianten unterstützt werden müssen.
Hier muss ich immer abwägen, was beibehalten werden muss und was einfach "korrigiert" werden kann.

Z.B. Kann ein Zeilenumbruch innerhalb der Parameter einer Prozedur ausdrücklich gewünscht sein oder es kann sinnvoll sein, einen solchen automatisch zu entfernen, um die Parameter in einer Zeile zu haben. Solche Fragen stellen sich viele.
Deswegen maskiert der Optimizer weiche (automatische) Umbrüche mit einem ESCAPE (das Kästchen am rechten Rand). So weiß er, dass dieser Umbruch auf jeden Fall entfernt werden kann.

Je nach Entscheidung können in beiden Fällen (Umbruch belassen oder entfernen) potenzielle Nutzer das Tool genau deswegen ablehnen.
Ich werde also viele Optionen anbieten müssen, allerdings wären weniger Optionen grundsätzlich natürlich wünschenswert.

[stahli]

... also das mit dem Einrücken funktioniert wie erwartet


Wer mal einen kleinen Einblick möchte:

Delphi-Quellcode:

                if SupportsIn(lItemBlockStart, [IDetectThen, IDetectElse, IDetectDo]) then
                  begin
                    if Supports(lItemBlockStart, IDetectElse, lDetectElse) then
                      lDetectCaseFlag := Supports(lDetectElse.ItemBlockStartLink, IDetectCase)
                    else
                      lDetectCaseFlag := False;
                    if (lDetectCaseFlag) then
                      currentRealAlign.LeftSpaceNext := currentRealAlign.LeftSpaceNext + 1 // Sonderfall Else zum Case  --> NEU <--
                    else
                      if (not lDetectExceptFlag) then
                        currentRealAlign.IncLeftSpaceMove; // sonst nach then/else/do eine Zeile/Anweisung einrücken (wenn Zeilenende)
                  end;

Zu den Format-Sonderfällen ist jetzt ein neuer Sonderfall hinzu gekommen.
Ich versuche das halt alles durch zugewiesene Eigenschaften zu deklarieren, die der Formatierer dann entsprechend umsetzt.
Da spielen dann noch die ganzen Verschachtelungen und Blöcke hinein.

[stahli]

Nochmal 4 Varianten von if-then-else...
Mal ist einrücken der nächsten Zeile sinnvoll und mal nicht.

Der Algorithmus sollte jetzt m.E. alle gängigen Formatierungsvarianten vernünftig optimieren.

[stahli]

Nur mal ein kleiner Zwischenstand für die reale Arbeit mit der aktuellen Suchfunktion: https://youtu.be/A1fURA7KFDk (2 Min)

Geht schon ganz gut aber ich muss das noch weiter ausbauen und optimieren.

[ConstantGardener]

Respekt! Das sieht schon sehr gut aus!

[stifflersmom]

Sehr vielversprechend!

Ich hoffe, ich kann das bald selbst mal ausprobieren.

[stahli]

Danke Euch!
Ich denke, im Dezember kann ich mal eine Testversion anbieten (incl. Installer usw.)


Zuvor will ich noch zwei Punkte ausbauen.

1) das Dockingprinzip
Die Suchformulare verhalten sich im Zusammenspiel mit der IDE etwas anders, je nachdem ob sie eingedockt sind oder nicht.
Vielleicht können ja diejenigen, die es demnächst mal testen möchten schon mal mitteilen, welche Auflösungen Ihr nutzt (wie ist die IDE ausgerichtet, gibt es mehrere Monitore?).
Würdet Ihr das Vollsuchformulare eher eindocken (nimmt halt dann recht viel Platz ein) oder das lieber über die IDE setzen (wie im Video zu sehen).
Oder doch auf einen zweiten Monitor?
Diesbezüglich habe ich noch keine optimale Lösung gefunden.

2) der Optimizer
Hier muss ich noch ein Problem klären, wenn die begin-end-Schachtelungen nicht aufgehen.
Dadurch, dass alle Methoden komplett aus der Unit entfernt und umsortiert neu eingesetzt werden, kann das noch zu Problemen führen.
Das muss ich natürlich noch erkennen und dann auf eine Umsortierung verzichten. Sonst wird die Unit "zerschossen", weil nicht mehr alles aufgeht.
An diesenigen, die das demnächst mal testen wollen: Würdet Ihr dann eine Umsortierung der Methoden überhaupt wollen?
In Interfaces und Klassen werden die Methoden nach Sektionen geordnet und dann innerhalb dieser nach Member (Funktionen/Prozeduren/Properties) sortiert und dann nochmal alphabetisch.
Die Methoden im Implementationsteil werden dann analog der Deklarationsreihenfolge sortiert.
Grundsätzlich finde ich das unbedingt sinnvoll, ist halt nur die Frage, ob man das für erste Tests gleich will. Wobei es natürlich funktionell auch keinerlei Nachteile hat, selbst wenn man es erst mal so nicht gewöhnt ist. Wer seinen Code in ein Versionssystem eincheckt würde damit jedoch wohl ein Problem haben.
Ich könnte natürlich auch den originalen Formatierer auf Ctrl-D lassen, so dass man standardmäßig weiter den nutzen kann.


Das wären jetzt noch meine Vorab-Überlegungen vor einer Testversion.

Für den Austausch würde ich mir dann einen Server auf Discord vorstellen...
(Ich habe schon einen angelegt, aber noch keine Erfahrungen damit. Hier mal der Link: https://discord.gg/5xHfSpvg Keine Ahnung, ob das so reicht.)

[jaenicke]

Zitat von stahli:

Vielleicht können ja diejenigen, die es demnächst mal testen möchten schon mal mitteilen, welche Auflösungen Ihr nutzt (wie ist die IDE ausgerichtet, gibt es mehrere Monitore?).

Full-HD und 4K.

Zitat von stahli:

Würdet Ihr das Vollsuchformulare eher eindocken (nimmt halt dann recht viel Platz ein) oder das lieber über die IDE setzen (wie im Video zu sehen).

Wenn man es eindocken kann, kann man es auch auf automatisch einklappen stellen oder loslösen. Diese Möglichkeiten sollten dann doch für alle Zwecke passen...

[stahli]

Einen Teil habe ich geschafft.
Ungedockte Formulare kann man jetzt auf beliebigen Monitoren platzieren (und auch an Monitorränder anheften).
Eindocken geht natürlich auch noch.

Standardmäßig werden dockbare Formulare offenbar ungedockt nur auf dem Monitor geöffnet, auf dem die IDE geöffnet ist.
An verschiedenen Stellen speichere ich daher die Suchformular-Positionen in eine Ini bzw. stelle sie wieder daraus her.
Es ist etwas Frickelei, scheint aber stabil zu funktionieren.

[stahli]

Jetzt werden auch innerhalb der IDE Interfaces in anderen Units gefunden und verarbeitet.

Anbei mal ein Auszug, wie eine vorher recht wüste Unit nach dem Optimieren aussieht.

(Die Performance passt noch nicht, aber da kann ich sicher noch etwas rausholen.)