UnitOptimizer

[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... 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 (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 von stahli:

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.

[TigerLilly]

Naja, grundsätzlich liegt Delphi eine reguläre Grammatik zugrunde - da ist nichts indeterministisch. Siehe auch:
https://condor.depaul.edu/ichu/csc44...k2/pascal.html

Aber die Kommentare und die Formatierung machen das natürlich schwieriger (darum gibt es ja auch die Tricks wie //1 //3 oder irgendwelche Tags etc). Da bist du rasch in der Verarbeitung natürlicher Sprache drin.

Während ich dem Umstrukturieren des Codes noch etwas abgewinnen kann, verstehe ich das Formatieren nicht - das kann Delphi ja schon + das macht es auch gut.

[DenkDirNix]

Zitat:

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.

Diese Dinge bekommt man sicher mit etwas Zusatz-Aufwand bei der Analyse in der Griff. Ich bin (bisher) nur über eine unschöne Sache gestolpert: Die Direktive "stdcall" kann tatsächlich sowohl mit Semikolon wie auch ohne an die vorausgehende Deklaration angehängt werden. Siehe z.B. in Source VCL.AxCtrls.pas:

Code:

var
  _OleCreatePictureIndirect: function(const PictDesc: TPictDesc; const iid: TIID;
    fOwn: BOOL; out vObject): HResult stdcall;
  _OleLoadPicture: function(stream: IStream; lSize: Longint; fRunmode: BOOL;
    const iid: TIID; out vObject): HResult; stdcall;

Das ist für einen Parser und dessen Programmierer nicht schön, da stimme ich Dir vollkommen zu. Typischerweise ist die Erklärung für solche Dinge in der Versions-Historie zu finden. Der Zwang zur Abwärts-Kompatibilität entschuldigt SEHR vieles.

[jobo]

Ich finde die "Strukturidee" eigentlich ganz gut. Hab mal den Film überflogen.
Leider wirkt es recht "monolitisch" und wenn Farbe, dann v ielleicht eher die Schriftfarbe, statt den Hintergrund und wenn Hintergrund dann vielleicht zeilenweise, statt Flattersatz entlang der Schrift.

Wieso machst Du das gerade in solch einem Test nicht interaktiv. Maßnahmen abschaltbar oder sogar interaktiv. Würde sicher die Fehlerfindung vereinfachen und Verständnis / Aha Effekt des Users auch.
Am Ende wäre es in meinen Augen sogar auch erstmal ein command line tool mit Regelset, Eingabedatei und Ausgabe.

Heute auch gern gesehen (Stichwort "moderne Programmierung"): Logging, wenigstens Fehlerausgabe auf Stdout, besser aber mehr, konfigurierbar.

Formatierung dito, müsste allerdings ebenfalls sehr individuell konfigurierbar sein, da es sonst keine Vorteile zu bestehenden Formatierern bietet oder?

[stahli]

Anbei mal eine zweite Testversion.
Ich habe noch einiges ergänzt, aber es ist noch nicht fertig.

Richtigen Kommentar sollte man unbedingt auch so kennzeichnen damit er nicht als auskommentierter Code interpretiert wird.
Vor allem, wenn er über einer Methode steht und dieser zuzuordnen ist.

Das kann dann so aussehen:

Delphi-Quellcode:

//: Text
{: Text :}
(*: Text :*)

Das ist aber das Einzige, das man beachten muss.


Im Moment macht noch Probleme, wenn Schlüsselwörter wie uses, var, const, begin usw. nicht allein in einer Zeile stehen.
Daran arbeite ich dann als nächstes.


@hsg
Schau mal, das sollte jetzt schon besser aussehen.

[jaenicke]

Bei Verwendung von etwas umfangreicheren Generics stürzt das Tool schlicht ab bzw. hängt mit voller Prozessorkernauslastung.

Dort kommen Konstrukte wie dieses vor (ob es daran liegt weiß ich nicht):

Delphi-Quellcode:

    class procedure RegisterStatusData<T, I: ICustomDataEntry; C: class, constructor, ICustomDataEntry; K: ICustomDataList<T>>;
...
class procedure TApplicationInterface.RegisterStatusData<T, I, C, K>;
begin
  RegisterInterfaceProvider<T>(
    function...
...

Die Unit kann ich leider nicht veröffentlichen, da sie Firmeneigentum ist.

// EDIT:
Jetzt bin ich etwas erstaunt. Die Ursache ist ein eigentlich absolut simpler Codeteil. Interessanterweise klappt es sobald ich eine der drei Propertys entferne. Der Code dürfte doch keinen Parser vor irgendwelche Probleme stellen...

Delphi-Quellcode:

unit Common.Core.ApplicationInterface;

interface

type
  TApplicationInterface = class
  public
    class property InterfaceProvider: IInterfaceProvider read GetInterfaceProvider;
    class property DummyProvider: IInterfaceProvider read GetDummyProvider;
    class property CurrentProvider: IInterfaceProvider read GetCurrentProvider;
  end;

implementation

end;

(Es ist egal, ob die Methodendeklarationen und -rümpfe dabei sind oder nicht.)