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.

[Uwe Raabe]

Zitat von stahli:

Dazu müsste ja immer die Deklaration gesucht und die dortige Schreibweise abgeglichen werden.

Nein, da steht ja nur As first occurence und nicht As declaration und der Formatter arbeitet ja nicht wie ein Compiler. Ich glaube auch nicht, dass das dateiübergreifend funktioniert, denn der Formatter bekommt ja entweder den markierten Code-Abschnitt oder die gesamte Unit. Aber das kann man ja gerne mal durch ausprobieren herausfinden.

[jaenicke]

Zitat von stahli:

Nach meinem Verständnis muss dazu das Projekt kompiliert sein und eine Verbindung zu den Codeteilen (Unit X, Zeile Y, Zeichen Xvon ... Xbis) vorliegen. Richtig?

So schlau ist der Formatter nicht, aber das braucht er auch gar nicht zu sein. Denn mir fällt kein einziges Beispiel ein, in dem es sinnvoll ist, ein ganzes Wort kontextabhängig anders zu schreiben.

Ich verwende ja den Formatter und bis jetzt war ich mit der Formatierung in Standardeinstellungen sehr zufrieden, wobei ohnehin nur sehr wenig überhaupt noch geändert wird, da ich ohnehin direkt "normal" schreibe. Das schließt auch Groß- und Kleinschreibung ein. Hier im Forum schreibe ich ja auch (meistens hoffe ich ) korrektes Deutsch.

Bei fremden Quelltexten ist es durchaus angenehm, wenn ich nur die ersten Vorkommnisse korrigieren muss und die Groß- und Kleinschreibung danach automatisch angeglichen wird.

[stahli]

Mit meiner Frage meinte ich eher das Refactoring.

Dazu muss der Compiler die verschiedenen binären Objekte (z.B. eine globale Variable "X") kennen und alle Codestellen in allen Units, die diese Variable benutzen.
Wenn ich ein Refactoring aufrufe und "X" in "XX" umbenenne, dürfte das nicht möglich sein, wenn das Projekt nicht kompiliert bzw. kompilierbar ist...
Ich denke mal, das dürfte so richtig sein.

Jetzt eine (vielleicht zu akademische?) Frage:

Ich hatte die Vorstellung, Umbenennungen in einem Interface auch in anderen Units (auch anderen Projekten) nachzuholen. Macht das überhaupt Sinn und wie würde man das aktuell händeln?

Mal ein Beispiel:

Ich habe zentral abgelegt eine Unit mit einem Interface und einer Property X.
Das Interface wird in 2 Projektgruppen verwendet.
Projektgruppe1 hatte es eingeführt. In Projektgruppe2 wurde die zentrale (selbe) Unit auch eingebunden und das Interface für neue Klassen benutzt.
In Projektgruppe2 werden neue Methoden und Properties in dem Interface deklariert. In Projektgruppe1 brauche ich nur meine Klassenvervollständigung starten und alle neuen Methoden und Properties werden in allen Klassen, die das Interface verwenden automatisch ergänzt (zumindest als Templates).

Soweit kein Problem, das sollte so funktionieren.


Jetzt die vermutlich akademische Frage:

Wenn ich innerhalb der Projektgruppe1 das Property X umbenenne in XX (und das in allen Klassen der Projektgruppe1 über ein Refactoring angepasst wird - sofern mir das irgendwann gelingen sollte), wie würde man in der Projektgruppe2 damit umgehen? Bzw. wie würde man das tun ohne mein Tool?

Die Projektgruppe2 wäre ja jetzt nicht mehr kompilierbar, da dort die Klassen (mit Property X) nicht der Deklaration des aktuellen Interfaces (mit Property XX) entsprechen. Ein Refactoring dürfte in dem Moment generell nicht mehr möglich sein.

Man wird also alle Codestellen suchen und händisch anpassen müssen. Mein Optimizer könnte dies ggf. in den Deklarationen und innerhalb der Getter und Setter automatisch übernehmen, nicht aber für die bisherigen Verwendungen von .X (die jetzt .XX heißen müssen) außerhalb der Getter und Setter.

Das ist sicherlich auch kein Standardfall, dass man Properties von Interfaces umbenennt, die in unterschiedlichen Projekten verwendet werden aber hatte jemand schon mal so etwas bzw. eine Meinung bzw. Umgang dafür?

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

[dummzeuch]

Zitat von jaenicke:

Zitat von stahli:

Nach meinem Verständnis muss dazu das Projekt kompiliert sein und eine Verbindung zu den Codeteilen (Unit X, Zeile Y, Zeichen Xvon ... Xbis) vorliegen. Richtig?

So schlau ist der Formatter nicht, aber das braucht er auch gar nicht zu sein. Denn mir fällt kein einziges Beispiel ein, in dem es sinnvoll ist, ein ganzes Wort kontextabhängig anders zu schreiben.

Spaßig ist es aber bei einzelnen Buchstaben:

x vs X und y vs Y -> gibt es mehrfach in unterschiedlichen Schreibeweisen in der RTL/VCL und diversen Bibliotheken

i vs I -> will man nie groß schreiben
l vs L -> will man nie klein schreiben
o vs O -> will man nie groß schreiben

Und dann gibt es da noch message vs. Message und natürlich private vs. Private und ähnliches, was aber wohl seltener vorkommt.

[dummzeuch]

Zitat von stahli:

Mit meiner Frage meinte ich eher das Refactoring.

Dazu muss der Compiler die verschiedenen binären Objekte (z.B. eine globale Variable "X") kennen und alle Codestellen in allen Units, die diese Variable benutzen.
Wenn ich ein Refactoring aufrufe und "X" in "XX" umbenenne, dürfte das nicht möglich sein, wenn das Projekt nicht kompiliert bzw. kompilierbar ist...
Ich denke mal, das dürfte so richtig sein.

Doch, das funktioniert durchaus, wenn auch in Grenzen:

Delphi-Quellcode:

function bla(_x: Integer): Extended;
begin
  // fiktive Formel kopiert von woanders, wo x verwendet wurde:
  Result := x * 5 - pi;
end;

In dem Fall kann man problemlos die Variable x in _x umbenennen lassen, obwohl der Code wegen der nicht deklarierten Variablen x nicht compiliert.

[stahli]

Ok danke. Das muss ich dann mal später genauer untersuchen wenn es mir überhaupt mal gelingen sollte, ein Refactoring über die OTA anzustoßen.

In dem Fall könnte ich über eine eine einzelne Anweisung wohl innerhalb eines Projektes gleich zeitig ein Property eines Interfaces umbenennen incl. automatisch Getter und Stter anpassen und die Änderung auch in alle benutzenden Klassen durchschleifen (dort auch incl. privatem Feld).
Wenn ich ein Refactoring grundsätzlich aufrufen kann, dann sollte das so machbar sein.

Ob die Anpassung dann auch in einem anderen externen Projeklt möglich ist, wäre dann eben nochmal zusätzlich zu klären (wenn die Anforderung überhaupt als interessant erachtet würde).


PS: Zu meiner Entschuldigung ... wenn ich in der Woche tagsüber schreibe habe ich i.d.R. kein Delphi verfügbar und jetzt am Wochenende versuche ich mich erst mal um die aktuelleren Dinge zu kümmern. Daher kommen sicher manchmal etwas komische Fragen von mir.

[stahli]

Der Umzug nach D.11 und Anpassung des Installers gingen bis hierher recht problemlos.

[stahli]

Kleiner Nebeneffekt...

Zwar muss man die automatisch erzeugten Units natürlich nicht formatieren, aber mir gefällt das so auf jeden Fall besser und ich finde es übersichtlicher.

[jaenicke]

Zitat von stahli:

Zwar muss man die automatisch erzeugten Units natürlich nicht formatieren, aber mir gefällt das so auf jeden Fall besser und ich finde es übersichtlicher.

Da der dort verwendete Parser ein wenig... eigenwillig... um nicht zu sagen fehlerhaft... ist, würde ich zumindest in der Projektdatei auf eigene Formatierungen verzichten...