UnitOptimizer

[stahli]

Ich bin dabei, ein Tool aufzubauen, das Units sortiert und Code ergänzt.

Es ist quasi eine Klassenvervollständigung, Codeformatierung und Codesortierung in einem.

Hier mal ein aktueller Zwischenstand als Video: https://youtu.be/cfKa3wuoEd0

Eine direkte Codeformatierung (Einrückung) habe ich noch nicht drin, will das aber auch noch ergänzen. Die anderen Features gehen für mich aber vor.

Die Abkürzung "prop" könnte man auch mit "property" ausschreiben lassen. Ebenso sind optional andere Voreinstellungen möglich, wenn dies gewünscht würde. Ich bin zunächst erst einmal von meinen Wünschen ausgegangen.

Ich würde das später sehr gern kommerziell anbieten, wenn es Nachfrage gibt.
Für öffentliche Tests ist es noch etwas früh. Dazu muss ich noch einiges ausbauen und ausbessern.
Sofern jemand Erfahrungen mit den OTA hat und daran mitarbeiten möchte, dann gebt Bescheid...



Ich hatte dazu schon einen Thread, der sich aber speziell auf die Interface-Unterstützung bezogen hatte. Da das Tool aber Units allgemein bearbeitet habe ich hier einen neuen Thread eröffnet.

[stahli]

Ich hatte jetzt erst mal keine Probleme festgestellt.

Aber danke für die Info!

Die Formatierung der Projektdateien ist natürlich generell recht überflüssig.
Evtl. Kann ich das auch optional komplett ausschließen oder nochmal etwas anpassen, falls es konkretes Probleme gibt.

[Aviator]

Zitat von stahli:

Ich hatte jetzt erst mal keine Probleme festgestellt.

Füg mal eine neue Unit zu dem Projekt hinzu wenn du die Formatierung durchgeführt hast. Danach zerhauts dir eigentlich alles. Passiert bei mir regelmäßig in der DPR Datei, da ich da auch gewisse Prüfungen durchführe und entsprechend Einrückungen vorgenommen habe. Nach dem Hinzufügen der Datei sind die aber immer wieder kaputt. Fällt dann meistens beim Einchecken ins VCS auf.

[stahli]

Oha! Vielen Dank!

Dann schließe ich die Formatierung von Projektdateien wohl doch besser gleich komplett aus!

[stahli]

Ich habe jetzt eine Formatierungssperre eingebaut.

Als Kriterium habe ich existierende "in" in den Uses-Klauseln festgelegt.
Das finde ich sicherer, als auf bestimmte Dateiendungen zu prüfen.

[stahli]

Mein nächster Punkt ist die bedingte Compilierung.
Hier soll geprüft werden, ob alle Varianten "aufgehen", also dass zumindest begin...ends ordentlich abgeschlossen werden.

Die Einrückungen von {$IFDEF ...} würde ich immer am Code orientieren. {$ELSE} und {$INDIF} sollen immer auf der gleichen Ebene stehen.
Mehrfache Verschachtelungen sollen so erkennbar sein.

Ich selbst habe damit noch nie gearbeitet. Habt Ihr noch Vorschläge oder Anmerkungen, was noch berücksichtigt werden muss?

Anbei ein Vergleich der originalen Formatierung und meiner Vorstellung...

[jaenicke]

Denk daran, dass auch Compilerdirektiven nach Delphiversion per if ausgeschlossen werden, weil sich dort etwas geändert hat.
Sprich: Nicht immer ist die Struktur so linear wie in deinem einfachen Beispiel.

Schau dir am besten mal die .inc Dateien der JEDIs oder so an, da sollte einiges zu finden sein.

[stahli]

Was es doch alles gibt in der Welt

Aber für meine Belange sollte das nicht störend sein, soweit ich das sehe.

Ich werde in den $If... Zweigen einfach nur alle Wege einzeln durchgehen, einrücken und auf die notwendigen "end"s prüfen.
Wenn die Bedingungen dabei für spätere Prüfungen umgestellt werden, sollte das nicht wirklich störend sein.

Es werden also alle Möglichkeiten durchgegangen, ohne auf reale Einstellungen Rücksicht zu nehmen.

Das wird wohl schon schwieriger als zunächst gedacht, aber ich taste mich mal vor...

[stahli]

Die bedingten Kompilierungen ziehen mir noch den Zahn.

Jetzt wollte ich mich endlich mal dem Problem der auf allen Wegen aufgehenden begin...ends widmen und schon stellt sich ein anderes Problem. Oder doch nicht?

Die Vererbungen und Verwendung von Interfaces in Klassendeklarationen soll der Optimizer berücksichtigen und entsprechenden Code vervollständigen. Dazu schlägt er auch in verwendeten Units (aus den Uses-Klauseln) nach.
In folgendem Beispiel werden vom Compiler je nach Situation unterschiedliche Units verwendet, was ich wohl nicht prüfen kann.
Ich würde zwar nicht davon ausgehen, dass in solchen Konstellationen verschiedene Basisklassen oder Interfaces zur Anwendung kommen, aber man weiß ja nie. :-/

Ich weiß jetzt nicht, was der richtige Ansatz ist.

Für das Einrücken von Code müsste ich immer alle möglichen Wege durchgehen (Bedingung erfüllt und nicht erfüllt).

Für das Prüfen auf gültige Bindungen (begin...ends z.B.) würde es reichen, nur die Wege zu prüfen, die der Compiler anhand seiner Einstellungen gerade gehen würde. Aber ich weiß ja nicht, ob der Programmierer mit oder ohne Compiler kompilieren wird.

Ich habe einfach überhaupt keine Idee, wie ich an das Problem heran gehen soll.

Vermutlich kann ich keine Unterscheidungen nach definierten Bedingungen machen und muss immer alle möglichen Wege durchgehen.
Beim Nachschauen in anderen Units nach Basisklassen und Interfacedeklarationen werde ich die erste passende Unit verwenden, unabhängig ob sie von einer bedingten Kompilierung abhängig ist oder nicht.

Ist schon alles sehr komplex geworden inzwischen.

Ja dazu evtl. jemand Erfahrungen oder Hinweise?

Delphi-Quellcode:

  uses .. 

 JvExExtCtrls, JvExtComponent, JvCaptionPanel

    //unterschiedliche pas dateien im Debugmodus / releaseModus   
   {$IFDEF DEBUG} , Codes_Debug {$ELSE}, Codes_Release {$ENDIF} ;