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]

Die Suchfunktion weiter ausgebaut und schon ziemlich komfortabel... https://youtu.be/bmfGo_2uvgI
Ich bin allerdings bei meinem Ansatz geblieben und strebe da eine Integration in meinen Optimizer an.

Was haltet Ihr davon?
(Von jaenicke weiß ich es ja schon. )

[jaenicke]

Das sieht von der Anzeige der Suchergebnisse ja ganz gut aus. Wenn der Rest auch etwas moderner aussähe und man das ganze in die IDE eindocken könnte, wäre das schon eine gute Umsetzung.

Zitat von stahli:

Was haltet Ihr davon?
(Von jaenicke weiß ich es ja schon. )

Ich brauche es nicht, aber das heißt nicht, dass ich es deswegen schlecht finde.

[Uwe Raabe]

Zitat von jaenicke:

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

Das haben wir vor ein paar Jahren bei einer 2 Mio. Zeilen großen Codebasis mal über die Kommandozeile gemacht. Seitdem ist das alles viel entspannter und einfacher geworden. Wenn über Jahre viele Entwickler mit unterschiedlichen Formatierungspräferenzen am Code arbeiten, tut ein solcher Hausputz manchmal Wunder.

[stahli]

@jaenicke

Das frei schwebende positionierbare Suchformular war zunächst natürlich eine Testlösung und geplant, das später einzubetten.

Allerdings finde ich das jetzt so DEUTLICH komfortabler. Das Suchformular muss ja nicht ständig offen sein. Allerdings sollte es leicht erreichbar sein und auch genügend Platz bieten.

Daher ist es eigentlich sinnvoller, es nicht in die IDE einzubetten. Möglich wäre das sicherlich, aber letztlich m.E. nur nachteilig.

Schöner machen kann man es ja noch (ich wüsste nur nicht wie genau).


@Uwe

Eine einheitliche Formatierung ist natürlich sinnvoll und es muss komplett auf Knopfdruck erledigt werden. Die Frage ist nur, was mal als "Standard" ansieht.
Der Compiler dürfte zwischen der originalen Standardformatierung von Delphi und der Formatierung durch den UO keinen wesentlichen Unterschied feststellen.
Es sind ja (abgesehen von den weichen Zeilenumbrüchen) nur Zeilen verschoben und Leerzeichen eingefügt bzw. gelöscht.

Abgesehen von einigen Kinderkrankheiten kann ich zumindest keine Probleme feststellen.

Mit Mio Codezeilen habe ich natürlich keine Erfahrungen.

[Uwe Raabe]

Zitat von stahli:

Eine einheitliche Formatierung ist natürlich sinnvoll. Die Frage ist nur, was mal als "Standard" ansieht.

Das ist - wie so oft - sicher Geschmackssache. Nur kommt man in einem Team nicht sehr weit, wenn jeder seinen eigenen Geschmack favorisiert. Daher legt man einen Style-Guide fest, der von dem verwendeten Formatierer (in unserem Fall dem Delphi eigenen) unterstützt wird. Wenn sich dann dieser Style-Guide noch weitestgehend an dem von Delphi orientiert, hat man auch keinen Bruch zwischen eigenem Code und den Delphi-Units, was dem schnellen Lesen und Erfassen sehr zugute kommt. Wenn ich mir überlege, wie viel Zeit ich mit dem Lesen von Code verbringe, summiert sich jede eingesparte Zehntel-Sekunde zu einer erklecklichen Zeitspanne auf. Ich wundere mich immer wieder über jeden, der diesen Vorteil zugunsten einer Vorliebe für eine eigene Formatierung verspielt.

Wenn man, wie ich, bei verschiedenen Kunden mit unterschiedlichen Style-Guides arbeiten muss, bleibt es natürlich nicht aus, daß man immer mal wieder was anders macht als vorgegeben. So verwende ich aus alter Gewohnheit immer mal wieder (eigentlich recht oft) das Hanging Begin (Zeilenumbrüche vor Begin in Steueranweisungen = Nein). Das lässt sich mit einem beherzten Ctrl-D aber recht schnell bereinigen.

Idealerweise wird vor jedem Check-In automatisch eine entsprechende Formatierung durchgeführt. Das sorgt dann auch für saubere Diffs in den ChangeSets.

[dummzeuch]

Zitat von stahli:

Der Compiler dürfte zwischen der originalen Standardformatierung von Delphi und der Formatierung durch den UO keinen wesentlichen Unterschied feststellen.
Es sind ja (abgesehen von den weichen Zeilenumbrüchen) nur Zeilen verschoben und Leerzeichen eingefügt bzw. gelöscht.

Abgesehen von einigen Kinderkrankheiten kann ich zumindest keine Probleme feststellen.

Mit Mio Codezeilen habe ich natürlich keine Erfahrungen.

Falls Du mal weinen willst: Ich kann Dir zum Testen die Unit-Tests des GExperts Code Formatters empfehlen. Zu finden im Subversion Repository auf Sourceforge. Die meisten davon habe ich hinbekommen, aber an einigen knabbere ich noch. (Einige schafft der Code Formatter von Delphi auch nicht.)

[stahli]

@dummzeuch

Danke. Ich habe sie mir mal geladen.
3 Abbrüche hatte ich. Die sind jetzt bereinigt.
Ich muss mir die Ergebnisse aber mal noch konkret durchsehen, ob diese "korrekt" sind.
Ist natürlich auch immer die Frage, was man unter korrekt versteht.
Da spielt ja auch immer der persönliche Geschmack hinein - bzw. welche unterschiedlichen Ergebnisse die einzelnen Optionen bringen...

Die testfile_LargeFile.pas braucht 13 Sekunden. 27.000 Zeilen in einer Unit sind ja aber sicherlich auch eher ungewöhnlich. Vielleicht lässt sich das auch noch etwas beschleunigen.
Mein Optimizer geht übrigens nicht nur strikt vorwärts durch die Zeilen und verschiebt die Wörter sondern zerlegt alles und baut das neu zusammen, um die Reihenfolge des Implementationsteils an den Interfaceteil anzugleichen. Das dauert dann halt etwas bei so großen Units.

Das aktuelle Ergebnis ist da aber definitiv auch noch nicht in Ordnung.
Das Problem muss ich noch in Ruhe analysieren.

Ein aktuelles Problem ist mit Sicherheit, dass der Optimizer zwischen echtem Kommentar und Auskommentierungen unterscheidet.
Durch diese Unterscheidungen kann er Kommentare besser im Quelltext einbinden oder z.B. mit Methoden zusammen verschieben.

Delphi-Quellcode:

{
procedure TestXYZ;
begin
end;
}

procedure TestB;
begin
end;

{: 
  Das ist die Prozedur Test.
  Author: StahliSoft
:}
procedure TestA;
begin
end;

Wenn die Prozedur TestA verschoben wird, dann bindet der Optimizer zuvor den darüber befinden echten Kommentar ( {: ... ) an die Methode und verschiebt diesen mit.
Den Block mit TestXYZ versteht er dagegen als Code und bindet diesen nicht an TestB.

Ich kann natürlich eine Option "KeineUmsortierungDesQuelltextes" oder "KommentarImmerAlsEchtenKommentarAnsehen" anbieten.

Aber erst mal muss ich mir die aktuellen Ergebnisse und Probleme mal genauer ansehen...

(Wo scheitern z.B. Du und der Code-Formatter von Delphi? Hast Du direkt mal ein Beispiel zur Hand? (gern auch per Mail))


@Uwe

Ich sehe schon einen Unterschied darin, ein eigenes Projekt zu entwickeln und in anderen Units etwas nachzulesen.
Wenn ich mit einer eigenen Formatierung gut zurecht komme, kann ich ja dennoch anders formatierten Code lesen und verstehen.
Den Hauptaspekt würde ich aber auf das eigene Projekt legen.

Das Wichtigste ist: Formatieren auf Knopfdruck!

Einrücken und Umbrüche von Hand zu schreiben würde ich unbedingt vermeiden wollen.
Daher habe ich immer Ctrl-D benutzt, auch wenn mir das Ergebnis an vielen Stellen nicht wirklich gefallen hat.

Das "hanging begin" habe ich auch noch in der Planung (wird nicht schwierig, habe nur andere dringendere Optionen in Arbeit). Ich habe das auch schon bei einem Tester gesehen und hätte nicht gedacht, dass diese Formatierung verbreitet sein könnte...
Aktuell behält der UO den Code bei wie er gegeben ist. Also "begin" bleibt hinter "then" oder in der neuen Zeile stehen. Als Option will ich anbieten, eine von beiden Varianten "erzwingen" zu können.


Daher mal:


@all

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht oder für wen käme das nie in Frage?

Delphi-Quellcode:

if x then begin
  y := 0;
  z := 0;
end;

[jaenicke]

Zitat von stahli:

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht oder für wen käme das nie in Frage?

Ich halte mich an Regel, dass man nicht mehrere Befehle in einer Zeile hintereinander hängen sollte, damit man nicht etwas davon übersieht und damit es weniger Probleme mit Versionsverwaltungen gibt. Und daher gehört auch das begin in eine eigene Zeile.

Beim Mergen gibt es nämlich ansonsten auch gerne mal "schöne" Ergebnisse, wenn nämlich beim automatischen Mergen das begin hinten in der Zeile entfernt wird, aber das end nicht. Diese Dinge kann man zwar dann korrigieren, aber besser ist es das begin in eine eigene Zeile zu schreiben, damit es beim Mergen auch separat behandelt wird.

Denn anders als der Delphi-Compiler handelt ein Merging-Tool nicht unbedingt semantisch korrekt... da ist es dann in Bezug auf das Ergebnis nicht egal wo das begin steht.

[dummzeuch]

Zitat von stahli:

Die testfile_LargeFile.pas braucht 13 Sekunden. 27.000 Zeilen in einer Unit sind ja aber sicherlich auch eher ungewöhnlich.

Deshalb habe ich es auch in den Unittests. Der originale DelForEx (auf dem der von GExperts aufbaut) brauchte dafür Ewigkeiten. Das war eine meiner ersten Verbesserungen. Jetzt ist es weniger als eine Sekunde.

Zitat von stahli:

(Wo scheitern z.B. Du und der Code-Formatter von Delphi? Hast Du direkt mal ein Beispiel zur Hand? (gern auch per Mail))

Der von GExperts scheitert vor allem an einigen Generics, siehe die Bug-Reports

Der von Delphi scheiterte bereits an so Sachen wie Variant Records (zumindest beim letzten Mal, als ich es versucht habe, es gibt einen QC-Report von mir dazu). Es gab noch weitere Fehler, aber die sind inzwischen wohl teilweise behoben. Ich benutze ihn aber eigentlich nicht, weil er lange zu fehlerhaft dafür war, deshalb habe ich keinen Überblick, was er kann/nicht kann.

Apropos: GExperts erlaubt es Bereiche von der Formatierung auszunehmen:

Delphi-Quellcode:

{(*}
hier; nicht; formatieren;{*)}

Das geht IIRC bei Delphi nicht, d.h. man ist dem Formatter ausgeliefert.

Zitat von stahli:

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht

Hier, wo der Finger leuchtet! Ich halte nichts davon, fuer begin/end eine eigene Zeile zu verschwenden. Ich formatiere immer so (bzw. lasse formatieren):

Delphi-Quellcode:

if bla then begin
  blub;
end else begin
  Trallala;
end;

[jaenicke]

Zitat von dummzeuch:

Der von Delphi scheiterte bereits an so Sachen wie Variant Records (zumindest beim letzten Mal, als ich es versucht habe, es gibt einen QC-Report von mir dazu). Es gab noch weitere Fehler, aber die sind inzwischen wohl teilweise behoben. Ich benutze ihn aber eigentlich nicht, weil er lange zu fehlerhaft dafür war, deshalb habe ich keinen Überblick, was er kann/nicht kann.

Aktuell (10.3) fällt mir nichts mehr ein was dort wirklich falsch formatiert wird. Variable Records wie in der Unit testfile_VariantExtendedRecord.pas sehen vollkommen in Ordnung aus, und auch die testfile_LargeFile.pas sieht auf den ersten Blick gut aus und ist in ca. 2 Sekunden formatiert.