UnitOptimizer

[DasWolf]

Zitat:

Zitat von TiGü (Beitrag 1440518)

Wer Quelltext nach Spalten ausrichtet, der schubst auch kleine Babyenten in den Teich!

Wo ist der Sinn darin?
Man liest von links nach rechts Zeile für Zeile.
Das ist doch keine Monatsbilanz oder dergleichen.
Je weiter a von b weg ist (a := b, a: b), desto mehr muss das Auge beim Lesen springen und man kann sich in der Zeile vertun.
Kein normaler Mensch würde auf diese Weise einen normalen deutschen/englischen/whatever Text lesen wollen, aber bei Quelltext soll das sinnvoll sein?

Ich gehe davon aus, dass es bei den Ausrichtungen weniger um das Lesen geht.

Das einzige, was absolut nicht geht, sind Ausrichtungen bei Methoden. Zu sehen bei

Delphi-Quellcode:

procedure FormCreate *lauter Leerzeichen* (Sender: TObject);

.
Absolutes NoGo.

[stahli]

@Ralf Kaiser + hsg

Man könnte sogar schnell 1 mal Ctrl-D drücken, wenn man so etwas suchen möchte und danach wieder Ctrl-O um alles wieder einzurücken, aber so richtig optimal ist das auch nicht. :-/

@dataspider

Es ging ja hier um eine automatische Formatierung, so dass das auf Knopfdruck erledigt wird.
Die Frage war jetzt hier konkret, wie einige Regeldetails umgesetzt werden sollten.

@TiGü + DasWolf

An einigen Stellen ist das schon sehr sinnvoll (siehe Beitrag #57), an anderen weniger - und die Vorstellungen dazu sind sicher sehr individuell.

[stahli]

Die Interface-Formatierung nimmt schon Formen an. :-)

Die "Getter+Setter"-Region wird ein kommerzielles Feature werden.

Die sonstigen Member habe ich zunächst nach der Reihenfolge "function, procedure, property" sortiert.
Macht das Sinn?

Da wären aber auch andere optionale Regeln möglich. Aber welche wären sinnvoll?
Es könnte auch (vorranging oder nachrangig) nach dem Member-Namen sortiert werden.
Oder es wird gar nicht automatisch sortiert.

Gleiches gilt für das Zusammenfassen von Gettern und Settern am Anfang und die interne Sortierung des Blocks.

Machbar wäre da vieles.

Ein echtes Problem sind zeilenweise Kommentare (also für eine ganze Zeile) und Leerzeilen.
Derzeit werden solche Zeilen an des Ende des Interfaces verschoben.

Die Frage wäre, wie solche Zeilen sonst zugeordnet werden sollen!?
Ich kann noch unterscheiden, ob ein Kommentar Code enthält oder nicht. Aber würde es Sinn machen, eine auskommentierte Prozedur innerhalb der echten Members einzusortieren?


Ich frage hier mal so umfangreich, weil ich entsprechende Lösungen dann auch an anderen Stellen entsprechend berücksichtigen kann.


PS: Die Ausrichtung der Getter und Setter untereinander habe ich vorhin in 5 Minuten erledigt. Das Parsing- und Optimierungskonzept scheint mir jetzt doch ganz brauchbar zu sein... :-)

[stahli]

So, hier mal eine erste richtige Testversion.

Das ist eine Exe mit zwei Editoren.
Eine Testunit wird links geladen und rechts überarbeitet dargestellt.

Den Text könnt Ihr testweise in Delphi kopieren.
Ebenso Eure Units per C&P in den linken Editor und rechts das Ergebnis anschauen.

Später wird der Optimizer natürlich in Delphi eingebunden und ist dann über Hotkey zu starten.

Hier ein Video dazu: https://youtu.be/8kKV0fHR_ys

Bisher gab es ja nicht so gute Resonanz auf meine Idee.
Wäre aber lieb, wenn Ihr Euch das mal real in einer ersten Testversion anschauen könntet.

Besondere Code-Konstrukte werden vielleicht noch nicht gehen, aber es ist auch noch nicht komplett fertig.

Aktuell fallen mir folgende Punkte ein, die noch nicht funktionieren dürften:
- overloads (natürlich nicht overlays ;-( )
- anonyme Methoden
- class vars
- und alles in Bezug auf Codevervollständigung natürlich
- Optionen sind noch eingeschränkt

Die Formatierung und Sortierung (das was jetzt etwa zu sehen ist) soll es kostenfrei geben (bis auf die Getter+Setter-Regionen).

Mit zwei kostenpflichtigen Versionen wird man dann noch Codevervollständigung incl. Interfaceunterstützung haben.
Das wird so weit gehen, dass man Interfaces in einem Projekt erweitern/verändern kann und die Klassen in diesem Projekt aber auch in anderen Projekten, die diese Interfaces verwenden, automatisch angepasst werden (abgesehen von der Logik natürlich).

[hsg]

Moin,

habe es eben mal ausprobiert: Meine Unit komplett kopiert und in dein Programm eingefügt. Leider startete damit eine Schleife unendlicher Zugriffsverletzungen, die jegliche Interaktion mit dem Programm verhinderten. Ich konnte es nur noch über den Taskmanager beenden :(.

Gruß
hsg

[stahli]

Ja, sorry.
Es ist noch in der Entwicklung und es kann noch einige Fälle geben, die noch nicht funktionieren.

Die ganze Funtionalität ist schon sehr komplex und Objekt-Pascal in der aktuellen Form auch sehr unstrukturiert (das denkt man im ersten Moment gar nicht).
Der Optimizer zerlegt die Unit und baut sie neu zusammen. Da kann es durchaus einige Fälle geben, die noch nicht berücksichtigt sind.
Das ist auch der Grund, dass ich derzeit noch keine Integration in Delphi vorsehe.

Ich weiß aber schon wie das geht. Der Optimizer könnte dann z.B. mit Crtl-Shift-O gestartet werden und den integrierten Formatter und die Codevervollständigung ersetzen.

Wenn Du mir mal Deine Unit mailen magst, würde ich als erstes mal schauen, wo es in Deinem Fall klemmt (könnte etwas dauern, da ich derzeit erst mal meinen neuen PC aufbaue und klären muss, wie ich Delphi CE wegen dem erreichten Installationslimit wieder ins Laufen kriege... Habe schon bei Emba nachgefragt.).
Variablen- und Klassennamen innerhalb der Unit könntest Du umbenennen und uses-Einträge könntest Du löschen, wenn Du magst. Die Unit muss also nicht kompilierbar sein. Nur die Struktur muss gleich sein, damit ich die Problemstelle finden kann.

Ansonsten würde mich mal interessieren, was Ihr generell davon haltet, wenn die Funktionalität vollständig Bugs raus und wären (also z.B. einfach anhand der beigefügten Demo-Unit).
Ich hätte mir eine solche Funktionalität schon seit Jahren gewünscht.

Die Codevervollständigung ist aktuell halt noch gar nicht drin. Die hatte ich aber in einer Vorversion auch schon mal realisiert. Das werde ich also dann auch wieder hin kriegen.

[DenkDirNix]

Ich bin - wie Du schon richtig vermutet hast - tatsächlich sehr überrascht von Deiner Einschätzung, dass Object-Pascal sehr unstrukturiert wäre. Immerhin kommt der Emba-Compiler meistens durch...:lol: Und wenn nicht liegt es zumindest bei mir doch meistens am User. Etwa in 110% der Fälle. Und in den dann noch verbleibenden auch.

Da ich selbst gerade an einem Parser arbeite würde mich aber interessieren, wo Du da auf in mangelhafter Struktur begründete Probleme stösst.

[stahli]

Schlüsselwörter haben unterschiedliche Bedeutungen, abhängig vom Kontext.
Manche Anweisungen sind mit einem Semikolon beendet, anderen folgen mehrere Zeilen, die mit Semikolon beendet werden können, aber nicht müssen.
Gleiche Schlüsselwörter können mehrfach in verschiedenen Abschnitten auftauchen.
Leerzeilen und unterschiedlichste Kommentare können überall enthalten sein.

Wenn man den Code interpretiert ist das nicht unbedingt ein Problem.
Auch eine einfache Formatierung (Einfügen und entfernen von Leerzeichen) ist noch machbar, aber wenn man den Code komplett neu ordnen möchte, dann wird das schon sehr komplex.

Je nach Kontext muss dann (wenn ich meine Zielstellung vor aus setze) dann der gleiche Abschnitt auch unterschiedlich formatiert werden. Z.B. sollte ein Var-Abschnitt im Interterface-Teil Leerzeilen haben und in einer Methode nicht.
Vielleicht möchten manche Entwickler auch gar keinen Zeilenumbruch, falls es z.B. nur um eine Variable geht (

Delphi-Quellcode:

var I: Integer;

).

Ich habe jedenfalls jetzt eine Vorstellung davon, warum der Compiler und Error Insight nicht immer gleichermaßen mit einem Quelltext klar kommen.
Offensichtlich werden da zwei unterschiedliche Parser genutzt und für beide alle Fälle gleich zu erkennen, wird nicht so einfach sein. Ist aber nur eine Vermutung meinerseits. Genaue Infos habe ich dazu nicht.

Delphi-Pascal lässt sehr viele Freiheiten und "Gestaltungsmöglichkeiten". Das ist zwar zunächst erst mal begrüßenswert, aber inzwischen würde ich es bevorzugen, dass es klarere Regeln gibt und die IDE den Entwickler dafür aber mehr unterstützt.
Der Code wäre zwar stärker in ein Korsett gezwungen, aber die IDE könnte den Entwickler besser unterstützen, da es klarere Regeln gäbe.


PS: Ist Dein Parser für Delphi-Code?

[Delphi-Laie]

Zitat:

Zitat von stahli (Beitrag 1449251)

Manche Anweisungen sind mit einem Semikolon beendet, anderen folgen mehrere Zeilen, die mit Semikolon beendet werden können, aber nicht müssen.

Daran ist nichts inkonsistent oder "unstrukturiert".

Manche arbeiten offenbar seit Jahrzehnten mit (Turbo-)Pascal und Delphi und haben trotzdem bis heute nicht erkannt, daß das Semikolon kein Beendigungszeichen ist (man kann es genauso gut als Einleitungszeichen bezeichnen und auch so verwenden, funktioniert gleichermaßen), sondern - wie auch sonst in der Schriftsprache - ein Trenn(ungs)zeichen ist.

Ich nahm mal vor vielen Jahren irgendein Delphibuch zur Hand, in dem ich schon auf den ersten Seiten die fehlerhafte Aussage fand, daß jede Anweisung mit einem Semikolon zu terminieren sei. Alles, was ich daraufhin noch tat, war, es wieder zuzuklappen.

[stahli]

Ob Du das Semikolon Ende-Zeichen, Einleitungszeichen oder Trennzeichen nennst ist egal.
Manchmal ist es erforderlich, manchmal optional, manchmal ist es unzulässig, je nach Kontext.
Manchmal beendet ein Semikolon einen Unit-Abschnitt, manchmal nicht.

Als Programmierer kommt man damit natürlich klar. Aber es bedeutet für den Parser mehr Aufwand und bringt mehr mögliche Fehlerquellen mit sich.
Das macht sich natürlich erst richtig bemerkbar, wenn man den Code automatisiert umstrukturieren möchte.

Das Semikolon ist auch nur ein Beispiel für die Unübersichtlichkeit der Codestruktur, sofern man nicht nur strikt vorwärts drüber liest und den Code interpretiert.