UnitOptimizer

[DieDolly]

Mal als Neuling-line eine Frage.
Was macht die Unit? Ich werde aus dem Video und der Einleitung nicht schlau.

[stahli]

Meinst Du, was der Optimizer macht?

Schaust Du mal bitte unter Beitrag #3? Da hatte ich das nochmal zusammengefasst.
Ansonsten gehe ich gern nochmal darauf ein, aber vielleicht klären sich die Fragen ja schon damit.

[stahli]

Ich habe eine Lösung für weiche Umbrüche gefunden. :-)

#0 ist für den Editor ein EOF - ist also untauglich.
Mit #27 funktioniert es aber erst mal gut.
Im Editor wird ein kleines Kästchen dargestellt, das aber (soweit ich testen konnte) nirgends stört.

Sofern sich doch mal noch Probleme ergeben, könnte ich das ESCAPE auch durch "//" ersetzen, das dann am Ende einer Zeile als weiches LineBreak interpretiert werden kann.
Fall jemand zufällig weiß, dass das ESCAPE unter bestimmten Umständen kritisch sein kann, dann gebt bitte mal Bescheid.

Bei neuen Formatierungen werden diese Umbrüche gegebenenfalls durch neue ersetzt.

Im Bild habe ich mal einige aufeinanderfolgende Optimierungen und Änderungen dargestellt.
Am Kästchen ist zu sehen, dass hier ein weicher Umbruch ist, der bei der nächsten Optimierung ggf. korrigiert wird. :-)

[p80286]

Irritierender Weise erfährt man in der Delphi-Hilfe nicht was die aktuellen Whitespaces sind.
Ich meine mich zu erinnern, das x1B(#27) ein Whitespace ist, aber das bezieht sich wohl auf (Turbo)Pascal.
Vielleicht kommst du an die aktuelle Backus-Naur-Form, da sollte alles drin stehen.

Gruß
K-H

[stahli]

@p80286

Ich wusste nicht mal, dass eine derartige standardisierte Dokumentation gibt.
Gefunden habe ich nichts passendes. Man kann sich ja auch nicht darauf verlassen, dass es bei einer aktuellen Regelung dauerhaft bleibt.
Ich werde das erst mal bei #27 belassen und einen Plan B in der Hinterhand behalten. Es kann ja auch mal sein, dass andere Tools nicht mit dem #27 klar kommen oder das selbst anders interpretieren.


@all

Ich könnte mir auch gut Einrückungen von SQL-Statements vorstellen.
Hätte da jemand Interesse?
Ich selbst brauche das nicht, aber ich könnte das mit einplanen.

Das könnte dann so aussehen:

Code:

  SQL1.Text := 'select * from Table.db '
             + 'where X=1 '
             + 'order by Y';

oder so:

Code:

  SQL1.Text := 'select * from Table.db' + #13#10
             + 'where X=1' + #13#10
             + 'order by Y';

Der Code würde dann harte (unveränderliche) Linebreaks enthalten, aber das "+" als erstes Zeichen in der nächsten Zeile und das fehlende Semikolon in der vorherigen würde zum Einrücken des Textes führen.

[p80286]

Ich hab da was in der D7 Hilfe gefunden:

Zitat:

Syntaktische Elemente

Delphi verwendet den ASCII-Zeichensatz mit den Buchstaben A bis Z und a bis z, den Ziffern 0 bis 9 und weiteren Standardzeichen. Die Sprache unterscheidet nicht zwischen Groß- und Kleinschreibung. Das Leerzeichen (ASCII 32) und die Steuerzeichen (ASCII 0 bis 31 einschließlich ASCII 13 für Zeilenvorschub) werden als Blanks bezeichnet.

Zugegeben nicht mehr ganz aktuell aber vielleicht ein Einstieg.
Angeblich soll die BNF sich auch in der Hilfe befinden, aber bisher hab ich sie noch nicht gefunden.

Gruß
K-H

[stahli]

Ich habe jetzt eine kleine Demoexe mit der man Vorschauen von optimierten Units anzeigen kann.
Optional gibt es vorerst die Möglichkeit, in Uses-Klauseln Units untereinander anordnen zu lassen.

Ist noch sehr provisorisch. Später werde ich die hier auch mal zum Testen hochladen.
Die Optionen sollen natürlich noch ausgebaut werden.

Anbei mal ein Screenshot von zwei Formatierungen der Uses-Klausel und hier ein kurzes Video: https://youtu.be/KHxoeZCwk7I (3min).

[stahli]

Eine Frage:

Macht es Sinn, Getter und Setter in Interfacedeklarationen in Regions zu verpacken?

Delphi-Quellcode:

  IWord = interface( IResultText )
    [sid_Word]
    {$REGION 'Getter+Setter'}
    function  _get_Text: string;
    procedure _set_Text( const Value: string );
    function  _get_PosMarkerList: TList<IPosMarker>;
    procedure _set_PosMarkerList( const Value: TList<IPosMarker>);
    function  IsSpace: Boolean;
    {$ENDREGION}
    function  IsFilled: Boolean;
    property  Text: string read _get_Text write _set_Text;
    function  AsText: string;
    property  PosMarkerList: TList<IPosMarker> read _get_PosMarkerList write _set_PosMarkerList;
  end;

Getter und Setter sind ja quasi nur Hilfskonstrukte und für die Nutzung und Verständnis des Interfaces nicht wirklich relevant.
Zugeklappt sieht das gut aus. Aber der Optimizer kann sicher nicht gezielt DIESE Regionen zuklappen.

Ich könnte auch eine Leerzeile zwischen Gettern+Settern und dem Rest einfügen.

Ok, dann ist die Region auch nicht wirklich störend.
Oder gibt es neben den optischen Bewertungen noch Gründe gegen Regionen (Probleme beim Debugging oder anspringen von Codezeilen o.ä.)?

Was meint Ihr zur Separierung von Gettern+Settern vom Rest eines Interfaces?

- Region
- Leerzeile
- Leerzeile mit //
- gar keine Trennung

[TiGü]

Zitat:

Was meint Ihr zur Separierung von Gettern+Settern vom Rest eines Interfaces?

- Region
- Leerzeile
- Leerzeile mit //
- gar keine Trennung

Ja, alles. Einstellbar machen.

[stahli]

Ich habe jetzt erst mal die Regionen fix drin.

Natürlich kann ich da je nach Bedarf mal noch verschiedene Optionen anbieten, aber ich werde jetzt vorrangig erst mal ein Standardverhalten umsetzen und die Logik möglichst übersichtlich halten (ist wirklich schon komplex genug).

Anbei mal ein paar aktuelle Screenshots.

In der DP lässt sich der formatierte Code nicht gut darstellen aber Ihr könnt Euch mal aus dem Anhang eine Beispielunit mit Eurem Delphi öffnen.
Die Regionen sind bei mir dann direkt zugeklappt. Ansonsten müsstet Ihr diese mal noch selber zusammenklappen um einen wirklichen Eindruck zu bekommen, wie sich das so anfühlt.

Mir gefällt das so schon sehr gut.

Ich suche jetzt noch eine Funktion in den OTA, mit der der Optimizer alle Regionen nach der Arbeit selbständig zusammenklappen kann.
Grundsätzlich komme ich jetzt ganz gut voran... :-)

[TiGü]

Wo hast du dir denn das mit den Unterstrichen für Setter und Getter abgeguckt? Das sieht ja gruselig aus. :shock:

[stahli]

Das habe ich mir ganz alleine ausgedacht :stupid: (glaube ich).
Ich finde es bei der Codevervollständigung sinnvoll, gleich zu sehen, dass man einen Getter oder Setter vor sich hat.

Es ist aber auch hier kein Problem, eine Option für verschiedene Schreibweisen einzurichten (und auch eine Checkbox für "erzwingen", so dass vorhandene Getter und Setter entsprechend umbenannt werden).

Also das würde ich mal nicht als Problem sehen wollen, höchstens als Geschmacksverirrung. :-)

[TurboMagic]

Zitat:

Zitat von KodeZwerg (Beitrag 1402953)

Ps: Ich hätte da auch etwas was mir in der IDE in Bezug auf Units fehlt oder ich habe es einfach noch nicht entdeckt.
Man kann ja intern für die IDE Hilfstexte an Methoden knüpfen.
Beispiel

Delphi-Quellcode:

///<summary></summary>

oder

Delphi-Quellcode:

///<returns></returns>

usw.
Solche Angaben meine ich, dafür einen IDE-Editor integrieren, das wär ein feature was mir fehlt.

Schon mal Strg-J im Editor gedrückt, dann s gedrückt und "summary" aus der Liste mittels Enter
ausgewählt (ggf. vorher mittels Cursor runter hinscrollen)?

[KodeZwerg]

Zitat:

Zitat von TurboMagic (Beitrag 1419168)

Zitat:

Zitat von KodeZwerg (Beitrag 1402953)

Ps: Ich hätte da auch etwas was mir in der IDE in Bezug auf Units fehlt oder ich habe es einfach noch nicht entdeckt.
Man kann ja intern für die IDE Hilfstexte an Methoden knüpfen.
Beispiel

Delphi-Quellcode:

///<summary></summary>

oder

Delphi-Quellcode:

///<returns></returns>

usw.
Solche Angaben meine ich, dafür einen IDE-Editor integrieren, das wär ein feature was mir fehlt.

Schon mal Strg-J im Editor gedrückt, dann s gedrückt und "summary" aus der Liste mittels Enter
ausgewählt (ggf. vorher mittels Cursor runter hinscrollen)?

Wenn ich CTRL-J drücke, erstellt der eine Neue Funktion.
Drücke ich dann "s" wird der Name der Funktion mit "s" ersetzt.
Obwohl Du nur einen Satz geschrieben hast kann ich es nicht nachvollziehen.

[EWeiss]

Zitat:

Wo hast du dir denn das mit den Unterstrichen für Setter und Getter abgeguckt? Das sieht ja gruselig aus.

Die Region für Getter und Setter [Getter-Setter] in den Interfaces zu erstellen sieht gut aus Damit ist das Interface gut überschaubar.
Habe es in meiner LiB(API) auch addiert ;)

gruss

[stahli]

Ich habe das Projekt nochmal neu angefangen und das Konzept geht bisher ganz gut auf. :-)

Bei Kommentaren möchte ich unterscheiden zwischen
- auskommentiertem Code und
- echten Kommentaren.

Auskommentierter (mehrzeiliger) Code wird eingerückt, als wäre er wirksamer Code - allerdings ohne Einfluss auf den echten umgebenden Code (also nur innerhalb des Kommentarblocks).
Die Klammern werden ganz links positioniert, so dass der Codefluss nicht so gestört wird.

Echter Kommentar wird mit einem zusätzlichen Doppelpunkt gekennzeichnet und dann eingerückt, wie man es kennt.

Meine Fragen:
- Was haltet Ihr davon?
- Würde eine Variante Sinn machen, bei Kommentaren mehrere Leerzeichen nicht auf eins gekürzt werden (oder sollten Leerzeichen gar nicht gekürzt werden)?
- Wären zusätzliche Kommentarformatierungen sinnvoll?

[stahli]

Hier mal ein Bild, wie es real aussieht.

Man sieht in der uses-Klausel (optionale) automatische Umbrüche nach jedem Eintrag und dann noch einige unterschiedlich interpretierte Kommentarblöcke.
"Auskommentierungen" behalten die Struktur von normalem Code. :-)

[DieDolly]

Gibt es die Möglichkeit die Leerzeile nach uses und const zu vermeiden?
Und gibt es dieses Tool schon zum Download?

[stahli]

Die Leerzeilen kann ich als Option einstellbar machen.
Aktuell ist sind oben die Umbrüche im Usesteil live umschaltbar.

Eine Testversion gibt es noch nicht.
Ich habe eine Exe, in die könnte man Quelltext mal per C&P kopieren, aber es fehlt noch zu viel, dass das wirklich Sinn macht.
Wenn die Formatierungen weitestgehend passen, lade ich die mal hier hoch. Sicher in ein paar Wochen.

Später soll es eine kostenfreie Version als Delphi-Experten für die Formatierung und Sortierung geben und zwei kostenpflichtige, die auch Klassen- und Interfacevervollständigung unterstützen.

[stahli]

Jetzt klappt auch die Einrückung bei Einzeiligen Code-Auskommentierungen :-)

(Dass begin-end hier noch nicht korrekt eingerückt wird, bitte einfach ignorieren. Es ist ja noch lange nicht fertig. Die Formatierung von auskommentiertem Code fühlt sich aber schon mal super an. :-) )

[stahli]

Machen Code-Einrückungen in ähnlicher Art wie im Screenshot irgendwie Sinn?
Würde jemand so etwas nutzen wollen und nach welchen Kriterien?

Ich selbst bin da unschlüssig.

Aktuell kann ich z.B. alle Worte nach einen ":" untereinander ausrichten lassen - und zwar automatisch, solange ":" in aufeinander folgenden Zeilen vorkommen.

Ich könnte auch sagen, dass eine Ausrichtung nur erfolgen soll, wenn die X-Ausrichtung z.B. 4 Zeichen Unterschied nicht übersteigt.
Dann hätte man ggf. Blöcke von Ausrichtungen, gebündelt für ein paar Zeilen.
Ich weiß aber nicht, ob das übersichtlich wird. Vermutlich eher nicht.

[Aviator]

Ich hatte das auch mal eine Zeit lang so gemacht. Allerdings händisch. Irgendwann wurde es mir zu blöd, die Zeilen immer nachzurücken wenn mal eine Variable mit einem längeren Namen hinzugefügt wurde. Diese Arbeit würde zwar von deinem Unit Optimizer abgenommen, aber ich hatte damals noch einen anderen Punkt, warum ich es nicht mehr mache. Bei Methoden hatte ich das aber nie gemacht. Das passt in meinen Augen gar nicht.

Wenn Variablen im Namen etwas länger sind und zugleich in einer anderen Zeile bspw. nur eine Zählervariable (wie i, j, k, ...) steht, dann ist der Abstand zwischen Variablennamen und Datentyp sehr groß. Somit kann man beim lesen relativ leicht in der Zeile verrutschen, was das Lesen von SourceCode im Endeffekt schwieriger macht anstatt leichter.

Also wenn du das einfügen wolltest, dann auf jeden Fall einstellbar/als Option. Dann kannst du, wie von dir vorgeschlagen, auch noch einstellen lassen, bis zu welcher Anzahl von Leerzeichen überhaupt eine solche Ausrichtung erfolgen soll.

So viel von mir dazu. :)

[DieDolly]

Zitat:

Also wenn du das einfügen wolltest, dann auf jeden Fall einstellbar/als Option.

Im Prinzip wäre es wünschenswert, wenn alles irgendwie mit einer Option versehen würde.
So kann jeder sich die Formatierungen aktivieren, die gewünscht sind.

[hsg]

Bei Typdeklaration mache ich so etwas nicht, allerdings bei der Variablendeklaration schon sehr gerne, da ich so optisch besser die Namen der Variablen erkennen kann. Allerdings benutze ich sehr selten die Auflistung von Variablen gleichen Types (var i,j,k : integer), sondern schreibe sie lieber untereinander in eigene Zeilen:

Code:

var
   i:  Integer; 
   j:  Integer;

An einer anderen Stelle könntest du mir sehr viel Arbeit abnehmen 8-):
Ich schreibe bei mehreren Zuweisungen untereinander das := immer in der gleichen Spalte, das ganze sieht dann ungefähr so aus:

Code:

   oWnd                 := TMeineFensterklasse.create( self ); 
   oWnd.Property1      := irgendEinWert;
   oWnd.AndereProp      := einAndererWert;

Für mich ist das optisch einfach besser lesbar. Ich erkenne sofort, wo Zuweisungen stehen und wem da was zugewiesen wird. Hab's mir durch eine andere Programmiersprache angewöhnt, die auch noch selbst die Groß- und Kleinschreibung von Feldern zum Teil selbst übernommen hat.

[Ralf Kaiser]

Zitat:

Zitat von hsg (Beitrag 1440501)

Ich schreibe bei mehreren Zuweisungen untereinander das := immer in der gleichen Spalte, das ganze sieht dann ungefähr so aus:

Code:

   oWnd                 := TMeineFensterklasse.create( self ); 
   oWnd.Property1      := irgendEinWert;
   oWnd.AndereProp      := einAndererWert;

Für mich ist das optisch einfach besser lesbar. Ich erkenne sofort, wo Zuweisungen stehen und wem da was zugewiesen wird. Hab's mir durch eine andere Programmiersprache angewöhnt, die auch noch selbst die Groß- und Kleinschreibung von Feldern zum Teil selbst übernommen hat.

Was ist wenn du mal im gesamten Code nach Stellen wie

Delphi-Quellcode:

oWnd := TMeineFensterklasse.create( self );

suchen willst? Bei so einer Formatierung weißt du nie, wie viele Leerzeichen da benutzt werden und musst anfangen mit RegExpressions zu suchen!

[stahli]

Danke Euch!

Ich werde für verschiedene Abschnitte (const, var, Klassendeklaration, Code usw.) einige Optionen anbieten.

Intern arbeite ich mit benannten "Tabs". Bei Propertys z.B. mit "Tab 'read'" und "Tab 'write'".
Der Formatierer schiebt die dann untereinander.

Ich kann noch einen Toleranzwert zuweisen, so dass man variieren kann zwischen etwa:

Code:

   oWnd                        := TMeineFensterklasse.create(self ); 
   oWnd.Property1              := irgendEinWert;
   I                           := 1;
   J                           := 2;
   oWnd.AndereProp             := einAndererWert;
   oWnd.NochGanzVollAndereProp := einAndererWert;

und

Code:

   oWnd      := TMeineFensterklasse.create(self ); 
   oWnd.Prop := irgendEinWert;
   I := 1;
   J := 2;
   oWnd.AnderePropLang         := einAndererWert;
   oWnd.NochGanzVollAndereProp := einAndererWert;

und

Code:

   oWnd      := TMeineFensterklasse.create(self ); 
   oWnd.Prop := irgendEinWert;
   I         := 1;
   J         := 2;
   oWnd.AnderePropLang         := einAndererWert;
   oWnd.NochGanzVollAndereProp := einAndererWert;

Wobei man dann halt auch mal damit leben muss, dass man subjektiv an der einen oder anderen Stelle doch lieber eine andere Einrückung hätte. Aber dann muss man halt für sich passende Durchschnittswerte finden...


@Ralf Kaiser

Ein sehr guter Einwand!
Vielleicht könnte man Emba dazu bewegen, bei Suchen Leerzeichen zu ignorieren oder immer auf eines zu kürzen.
Keine Ahnung ob das machbar wäre.

[dataspider]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1440502)

Zitat:

Zitat von hsg (Beitrag 1440501)

Ich schreibe bei mehreren Zuweisungen untereinander das := immer in der gleichen Spalte, das ganze sieht dann ungefähr so aus:

Code:

   oWnd                 := TMeineFensterklasse.create( self ); 
   oWnd.Property1      := irgendEinWert;
   oWnd.AndereProp      := einAndererWert;

Für mich ist das optisch einfach besser lesbar. Ich erkenne sofort, wo Zuweisungen stehen und wem da was zugewiesen wird. Hab's mir durch eine andere Programmiersprache angewöhnt, die auch noch selbst die Groß- und Kleinschreibung von Feldern zum Teil selbst übernommen hat.

Was ist wenn du mal im gesamten Code nach Stellen wie

Delphi-Quellcode:

oWnd := TMeineFensterklasse.create( self );

suchen willst? Bei so einer Formatierung weißt du nie, wie viele Leerzeichen da benutzt werden und musst anfangen mit RegExpressions zu suchen!

Und wenn mal bei der 100. Zeile der Bezeichner 1 Zeichen länger ist, rückst du die 99 andernen 1 Zeichen weiter...
Wenn man sonst nichts zu tun hat :)

Frank

[hsg]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1440502)

Was ist wenn du mal im gesamten Code nach Stellen wie

Delphi-Quellcode:

oWnd := TMeineFensterklasse.create( self );

suchen willst? Bei so einer Formatierung weißt du nie, wie viele Leerzeichen da benutzt werden und musst anfangen mit RegExpressions zu suchen!

Das ist korrekt, aber bisher habe ich auch nicht wirklich nach solchen Sachen gesucht. Eine Suche nach "TMeineFensterklasse.create" hat mir eigentlich in solchen Fällen gereicht

[DasWolf]

Zitat:

Zitat von dataspider (Beitrag 1440513)

Zitat:

Zitat von Ralf Kaiser (Beitrag 1440502)

Zitat:

Zitat von hsg (Beitrag 1440501)

Ich schreibe bei mehreren Zuweisungen untereinander das := immer in der gleichen Spalte, das ganze sieht dann ungefähr so aus:

Code:

   oWnd                 := TMeineFensterklasse.create( self ); 
   oWnd.Property1      := irgendEinWert;
   oWnd.AndereProp      := einAndererWert;

Für mich ist das optisch einfach besser lesbar. Ich erkenne sofort, wo Zuweisungen stehen und wem da was zugewiesen wird. Hab's mir durch eine andere Programmiersprache angewöhnt, die auch noch selbst die Groß- und Kleinschreibung von Feldern zum Teil selbst übernommen hat.

Was ist wenn du mal im gesamten Code nach Stellen wie

Delphi-Quellcode:

oWnd := TMeineFensterklasse.create( self );

suchen willst? Bei so einer Formatierung weißt du nie, wie viele Leerzeichen da benutzt werden und musst anfangen mit RegExpressions zu suchen!

Und wenn mal bei der 100. Zeile der Bezeichner 1 Zeichen länger ist, rückst du die 99 andernen 1 Zeichen weiter...
Wenn man sonst nichts zu tun hat :)

Frank

Dann benutzt man Shift + Alt.
Ganz easy. :wink:

[TiGü]

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?

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