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.

[jaenicke]

Zitat von HeZa:

Bei ausgerichteten Zuweisungen, muss man für das Suchen aller Zuweisungen einer Variablen schon mit RegEx arbeiten.

Oh ja, das war bei altem Code bei uns in der Firma auch ein Problem. Heute kann man überall ganz normal suchen, weil wir das überall korrigiert haben.

[DenkDirNix]

Ich hoffe, das wird hier nicht als unpassende Werbung angesehen, aber u.a. für das rein Syntax-orientierte Finden von Zuweisungen eignet sich schon der derzeitige Stand meines aktuellen Entwicklungs-Projektes https://www.delphipraxis.net/204052-...ml#post1462457

[stahli]

Die zwei genannten Probleme sind tatsächlich nachteilig.

Zur Codeverwaltung kann ich nichts sagen. Damit komme ich so oder so nicht klar.
Ich sichere die Quellen zwar in Github aber wenn es mal ein Problem gibt hat mir das bisher nicht geholfen.
Bin halt ein alter Sack ohne Ahnung. :-/

Die Suche funktioniert natürlich auch schlechter durch die unterschiedlich vielen Leerzeichen.
@jaenicke, was habt Ihr da wie konfiguriert?

Ich möchte z.B.

Code:

xyz := 123;
xyz :=     123;
xyz:=123;
xyz:=   123;

finden.

Ab liebsten durch die Suche von:

Code:

xyz := 123;

oder noch besser von

Code:

xyz:=123;

Bei der Suche müssten wohl im ersten (einfacheren) Fall die Leerzeichen so maskiert werden, dass 0, 1 oder mehrere Leerzeichen akzeptiert werden.
Im zweiten Fall müsste wohl erst eine Funktion bestimmte Leerzeichen (hier vor und nach ":=") einfügen und dann suchen.
Oder man akzeptiert einfach zwischen ALLEN Zeichen ein Leerzeichen...

Kann man so etwas konfigurieren, ohne das bei jedem Suchvorgang einstellen zu müssen? Das wäre super!

[jaenicke]

Zitat von stahli:

Ich möchte z.B.

Code:

xyz := 123;
xyz :=     123;
xyz:=123;
xyz:=   123;

finden.

Ab liebsten durch die Suche von:

Code:

xyz := 123;

Wenn du das Häkchen bei regulären Ausdrücken setzt, kannst du die normal in der Suche verwenden, sprich:

Code:

xyz[ ]*:=[ ]*123

Also einfach nur xyz, eine beliebige Anzahl Leerzeichen, ...

Zitat von stahli:

Kann man so etwas konfigurieren, ohne das bei jedem Suchvorgang einstellen zu müssen? Das wäre super!

Nein, von daher wäre es sinnvoller ein solches Plenking schlicht nicht zu machen statt hinterher nach Lösungen dafür zu suchen.

[stahli]

Ähh, jetzt bin ich überrascht...

Du hattest doch oben geschrieben:

Zitat von jaenicke:

Zitat von HeZa:

Bei ausgerichteten Zuweisungen, muss man für das Suchen aller Zuweisungen einer Variablen schon mit RegEx arbeiten.

Oh ja, das war bei altem Code bei uns in der Firma auch ein Problem. Heute kann man überall ganz normal suchen, weil wir das überall korrigiert haben.

Ich hatte das so verstanden (und kann auch nichts anderes heraus lesen), dass Ihr eine Lösung habt, um ganz normal zu suchen (trotz Einrückungen und Dank einer Konfiguration).


Ok, dann meintest Du vermutlich, normale Suche bei angewählter Regulär-Checkbox und Maskierung von Leerzeichen im Suchfeld? Das wäre dann aber keine normale Suche aus meiner Sicht...!?


Auf eine solche Codeformatierung zu verzichten, weil Delphi keine passende Suchfunktion anbietet, finde ich allerdings nicht nachvollziehbar.
Dafür kann sich doch eine Lösung finden lassen. Unabhängig von meinem Formatter würde es möglich sein und ja Sinn machen, dass Emba eine Suchoption "Leerzeichen und Umbrüche ignorieren" sowie vielleicht "Klammern ignorieren" anbietet. Das hätte ich früher auch schon öfters für sinnvoll gehalten.
Evtl. könnte man auch eine eigene Suchfunktion implementieren, die so einen regulären Ausdruck automatisch verwendet.
Also Lösungen sehe ich da durchaus.


Wenn das Suchproblem nicht bestehen würde (bzw. gelöst wäre), würdest Du dann eine solche Formatierung sinnvoll finden?


Natürlich kann ich im Optimizer auch eine Option anbieten, dass solche Einrückungen abgesehen vom linken Zeilenbeginn nicht erfolgen sollen. Das wäre technisch gesehen nur eine Auslassen der Funktion "AusrichtungDerVirtuellenTabulatorenUntereinander" . Das würde das Suchproblem sofort vermeiden. Ich finde eine solche Formatierung aber sehr hilfreich.

[jaenicke]

Zitat von stahli:

Wenn das Suchproblem nicht bestehen würde (bzw. gelöst wäre), würdest Du dann eine solche Formatierung sinnvoll finden?

Ich persönlich finde es unübersichtlicher, aber das ist eben sehr subjektiv.

Zitat von stahli:

Ich hatte das so verstanden (und kann auch nichts anderes heraus lesen), dass Ihr eine Lösung habt, um ganz normal zu suchen (trotz Einrückungen und Dank einer Konfiguration).

Nein, die Lösung war die Standard-Formatierung zu verwenden und eben alles nach und nach dahingehend zu formatieren.

Der Quelltext ist so auch für mich deutlich besser lesbar, weil es einfach immer genauso formatiert ist wie die meisten Codesnippets im Internet und auch die RTL- und VCL-Quelltexte selbst. Exotische Formatierungen sind ja zum Glück deutlich in der Minderheit.

Aber letztlich jage ich im Zweifelsfall zuerst den Formatter von Delphi drüber, wenn Quelltext anders formatiert ist. Von daher stört mich das wenig, ich muss es ja nicht so lesen.

Ein weiterer Vorteil ist, dass man nicht Änderungen im Repository sieht, weil jemand anders formatiert, sondern nur die echten Änderungen. Und die Differenzansicht funktioniert dann auch viel besser, sprich ist übersichtlicher, wenn nicht noch Leerzeichen mehr oder weniger dazwischen hängen.
Ja, solche Änderungen kann man ausblenden, aber das ändert nichts daran, dass technisch unnötige Änderungen im Repository landen.

Bei uns wird jede einzelne Änderung vor dem Einchecken noch einmal geprüft um nicht Debugcode oder unbeabsichtigte Änderungen einzuchecken. Da sind verschiedene Formatierungen nur hinderlich. Und dazu kommt, dass das Mergen weniger Konflikte verursacht, wenn alle gleich formatieren.

Das erreicht man aber natürlich auch, wenn alle die gleiche eigene Formatierung verwenden (z.B. mit deinem Tool). Ich kenne allerdings kein Team, bei dem alle eine solche verwenden, das sind meistens eher nur einzelne Entwickler.

[stahli]

Ok, kann man natürlich so sehen.

Ich finde den Code mit "Tabulatoren" übersichtlicher und attraktiver. Ist natürlich Geschmacksache und und im Optimizer optional auch abwählbar.

Wichtig ist natürlich, dass die gewünschte Formatierung IMMER AUF KNOPFDRUCK erreichbar ist.
Von händischen Formatierungen halte ich nichts. Bisher habe ich immer die die Standardformatierung genutzt, auch wenn sie mir nicht ganz gefallen hat.



Mal zur Suche:

Eine generelle Änderung der Suchfunktion würde auch Suchen über Umbrüche ermöglichen.
Wenn man z.B. "Vorname, Nachname, Alter" sucht, weil man die irgendwo als Parameter verwendet hat, dann wäre doch eigentlich schön, wenn die IDE eine Codezeile auch findet, wenn vor "Alter" ein Zeilenumbruch eingefügt ist weil die maximale Zeilenlänge sonst überschritten wird.

Noch cooler wäre wenn der Suchbegriff auch so etwas wie:
procedure SetPerson(const Vorname, Nachname: String; const Alter: Integer);
oder
procedure SetPerson(const aVorname, aNachname: String; const aAlter: Integer);
findet.

Ich glaube, ich habe gerade Blut geleckt....

[HeZa]

Für solche Suchen verwende ich DocFetcher.

Dafür exportiere ich täglich alle Source-Repositories und alle Datenbankstrukturen, Trigger, Stored Procedures (IBExpert sei Dank), lass noch ein Tool darüber laufen, dass mir die SQLs aus allen DFM- und FastReport-Dateien extrahiert (um diese komischen Sonderzeichen und Umbrüche loszuwerden).

Vorteile:
* Die Suche darüber ist dann sehr schnell, die Antwort dauert immer nur 1-2 Sekunden.
* Man kann zwei Wörter suchen die bis zu x Wörtern auseinander liegen.

Nachteile:
* Ist eine Wortsuche (* wird allerdings unterstützt), Sonderzeichen wie , := ; " werden nicht gefunden
* Es ist immer der Stand vom Morgen des aktuellen Tages

Vermissen möchte ich das trotzdem nicht mehr.

Ciao HeZa

[stahli]

Ich habe mal eine kleine Testsuche gebastelt... https://youtu.be/LzHs3a2NSZc

Das ist noch recht provisorisch und unansehnlich aber die Funktionalität finde ich schon mal cool.

Was haltet Ihr davon?

Hat jemand Lust, daran mit zu arbeiten?
Ich kann mir vorstellen, dass das sehr nützlich werden kann.


(Jetzt muss ich mal noch einen kleinen Nachtspaziergang machen, um die Kopfschmerzen raus zu laufen und ein wenig runter zu kommen. Kennt Ihr sicher auch nach Doppelschicht am Rechner... )

[jaenicke]

Eine nützliche Codesuche zu bauen ist gar nicht so einfach, da viele Optionen berücksichtigt werden sollten. Zum Beispiel in welchem Unitabschnitt man suchen möchte und ob in Code, Strings oder Kommentaren oder auch ob auch in Formulardateien gesucht werden soll.
Wie ich auf diese Liste komme? Dies ist in den GExperts in der Grep-Suche umgesetzt.

Ich selbst finde Regular Expressions flexibler als eine solche manuelle spezielle Suche.

Wenn du eine solche Suche implementieren möchtest, würde ich es aber im Code der GExperts tun und das Ergebnis an Thomas schicken. Wenn das gut funktioniert, nehme ich an, dass er es dann in seine Releases integrieren würde.
Das hätte den Vorteil, dass die IDE-Integration und die Ergebnisdarstellung schon sehr gut vorhanden sind.