UnitOptimizer

[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]

Danke Euch.

Das Hauptziel meines Tools ist eine Codevervollständigung incl. Interfaceunterstützung.
Das ist in der Demo noch gar nicht drin.

Zweites großes Ziel ist die Sortierung der Unit. Mich nervt es immer, wenn die Methoden im Implementationsteil "irgendwo" stehen.
Bei der Umsortierung von Code sollen alle Lesezeichen und Breakpoints erhalten bleiben und mit verschoben werden.
Das hat in meiner früheren Version schon grundsätzlich funktioniert, aber noch nicht vollständig.

Die Codeformatierung gehört dann natürlich mit dazu. Die ist aber eher ein Nebenprodukt, enthält aber zur Delphi-Formatierung m.E. auch noch einige Vorteile (Ausrichtungen untereinander, weiche Umbrüche und 3 Kommentar-Stile).



Die Exe ist jetzt nur während der Entwicklungszeit zum testen da. Später soll das Tool als Delphi-Experte in Delphi eingebunden werden und den Code im Editor auf Knopfdruck überarbeiten.
Der Flatter-Satz ergibt sich so, weil der Quelltext so analysiert wird. Es soll ja nicht schön aussehen, sondern ist eine optische Kontrolle während der Entwicklungszeit, was mein Parser in den Texten erkennt. Ein Logging habe ich zusätzlich.

Delphi-Pascal selbst finde ich weiterhin eine super Sprache aber sie ist tatsächlich sehr komplex zu analysieren, eben weil sie der natürlich Sprache ziemlich ähnelt.
Für einen Parser wäre es letztlich am einfachsten, wenn man statt I := 0; so etwas schreiben würde wie Assign, I, 0 .
Alles, was dann an Freiheiten noch kommt, erhöht die Komplexität der Sprache. Für die Programmierer macht es allerdings auch einiges einfacher und es fühlt sich natürlicher an.

Ich habe also nichts gegen Delphi-Pascal, sondern wollte nur sagen, dass es doch überraschend komplex ist - vor allem wenn man etwas umsortieren möchte.

[samso]

Hast Du Dir den "Castalia Delphi Parser" schon angesehen?

[jaenicke]

Zitat von samso:

Hast Du Dir den "Castalia Delphi Parser" schon angesehen?

Den habe ich auch schon verwendet und erweitert. Den kann ich absolut empfehlen um damit einen Syntaxbaum aufzubauen, den dann entsprechend zu transformieren und wieder zu schreiben.

Zitat von stahli:

Für einen Parser wäre es letztlich am einfachsten, wenn man statt I := 0; so etwas schreiben würde wie Assign, I, 0 .
Alles, was dann an Freiheiten noch kommt, erhöht die Komplexität der Sprache. Für die Programmierer macht es allerdings auch einiges einfacher und es fühlt sich natürlicher an.

Ich hoffe doch, dass du einen echten Parser benutzt und nicht einfach zeilenweise analysierst?!
Das hört sich jetzt im Kontext eines Parsers etwas seltsam an.

[stahli]

Ich habe keinen fertigen Parser benutzt, sondern alles selbst geschrieben.
Was meinst Du mit "nicht einfach zeilenweise"?

Meine Vorgehensweise ist etwa so:
- Zerlegen der Unit in einzelne Worte (Namen und Zahlen werden als Ketten behandelt, sonstige Zeichen sind immer separiert (Wörter sind dann ein Zeichen lang), LineBreaks sind auch "ein Wort")
- Die Wörter sind Objekte, die den Text beinhalten. Diese Objekte werden in Listen gespeichert.
- Den Objekten werden dann durch den Parser Tags hinzugefügt (z.B. "IstEinSchlüsselwort", "BeginnKommentar", EndeKommentar" usw.)
- Die Tags werden dann ggf. verschoben, um z.B. das Ende einer Methode zu markieren oder auch das Ende einer Unit.
- Dann werden die einzelnen Blöcke ausgeschnitten und in anderer Reihenfolge wieder eingefügt.
- Dann geht ein Formatierer durch die Liste und fügt z.B. Leerzeichen ein oder entfernt welche.
. Zum Schluss werden die Texte aus den Objekten wieder in eine Stringlist geschrieben.

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