UnitOptimizer

[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

Delphi-Quellcode:

I := 0;

so etwas schreiben würde wie

Delphi-Quellcode:

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:

Zitat von samso (Beitrag 1449283)

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:

Zitat von stahli (Beitrag 1449279)

Für einen Parser wäre es letztlich am einfachsten, wenn man statt

Delphi-Quellcode:

I := 0;

so etwas schreiben würde wie

Delphi-Quellcode:

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.

[jaenicke]

Ein echter Parser geht so vor, dass er unabhängig von Zeilenumbrüchen einfach zeichenweise durchgeht und jeweils schaut, wenn er z.B. ein Wort oder Satzzeichen findet, ob das an der Stelle laut Grammatik erlaubt ist und entsprechend verarbeitet.

Bei dem Castalia Parser ist das z.B. so gelöst, dass es eine Methode gibt, die eine Unit parst. Stößt die auf das Schlüsselwort interface, wird eine Methode aufgerufen, die dieses parst. Findet die einen Bezeichner, kann das nur ein Unitname sein usw., so dass man immer weiß wo man gerade ist und was an der Stelle richtig oder falsch ist.

Da man Konstrukte wie Typdeklarationen innerhalb von Methoden hat usw., ist das anders auch nur schwer abzubilden. Schau dir am besten einfach mal an wie das dort läuft. Der Quelltext ist ziemlich einfach zu verstehen.

Klar ist jedenfalls, dass man nie alle Formatierungen und Konstrukte verstehen können wird, wenn man nicht wirklich entsprechend der Grammatik parst.

[Fritzew]

Was machst Du mit defines und co?
also so etwas wie:

Delphi-Quellcode:

{$IFDEF USENEWPARTS}
  irgendwas das nicht compiliert
{$ELSE}
 s := 'Bla'{$IFDEF CPU64}+'64 {$ENDIF}   + Blub;
{$ENDIF}

Eine Weiterentwicklung des Castalia Parsers findest Du hier:
https://github.com/RomanYankovsky/DelphiAST

Ist auf jeden Fall ein ambitioniertes Projekt 8-)

[stahli]

So, mein Delphi CE läuft wieder auf dem neuen Rechner. :-)

Das $ifdef habe ich gleich mal angepasst. Siehe Screenshot.
3 kleine Änderungen musste ich noch einarbeiten.

Jetzt werde ich mich mal um "das hsg-Problem" von oben kümmern... :-)

[stahli]

Ich habe von hsg mal zwei Units mit einigen Herausforderungen bekommen :-).
Da sind halt schon einige Stile drin, die ich so nicht kenne. Jetzt will ich dem Optimizer beibringen, damit umzugehen und die Unit u.a. neu zu sortieren, ohne das Styling dabei zu zerschießen...

Hier dazu mal ein neuer Zwischenstand.

Um z.B. Beschreibungen über Methoden diesen zuzuordnen, müssen sie als "echte Kommentare" gekennzeichnet werden.
Dann werden sie zur Methode zugehörig interpretiert und mit verschoben (der Optimizer passt ja regelmäßig die Reihenfolgen der Methoden an).

Im Gegensatz dazu sieht man unten, dass "Auskommentierungen" wie Code behandelt werden. Wenn "auskommentierter Code" über einer Metho steht, wird er dieser also nicht zugeordnet und würde entsprechend nicht mit der Methode umsortiert.

Wenn man die Funktionalität des Optimizers nutzen möchte, muss man also Kommentare immer passend auszeichnen.

Echte Kommentare werden mit ":" oder "!" eingeleitet, wobei ':' noch in den Codefluss eingerückt wird und bei "!" keine automatische Anpassung erfolgt (hier also der Programmierer komplett selbst das Aussehen bestimmt).

Ich denke, mit dieser Anforderung (echte Kommentare besonders zu kennzeichnen) sollte man leben können. Nur so kann der Optimizer diese unterschiedlich behandeln.

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

[hoika]

Hallo,
zumindestens fehlt ein uses für IInterfaceProvider.

[jaenicke]

Das habe ich alles herausgeworfen, im Original lässt sich die Unit natürlich kompilieren. Ich glaube auch nicht, dass das eine Rolle spielt, denn sonst müsste man ja angeben können wo diese Units liegen usw., zumal es dem Parser egal sein sollte. Die Verknüpfungen werden ja auf höherer Ebene erstellt.

[TigerLilly]

Zitat:

Zitat von stahli (Beitrag 1449622)

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 finde ich problematisch, weil es schon einige Konventionen für Kommentar gint. MMX hat //1 und //2, PasDoc hat auch ein paar Konventionen. Wäre es nicht besser, den kommentierten Code extra zu kennzeichnen? Oder das konfigurierbar zu machen?

[stahli]

Ich danke Euch.


@jaenicke

class var, methodes und properties sowie anonyme Methoden werden noch nicht unterstützt.

Ich schaue mir das aber mal als nächsten Punkt an.
Kann wieder ein paar Tage dauern. Ab morgen muss ich wieder arbeiten... :-/


@TigerLilly

Optional könnte man das erwägen.
Allerdings nutzt man Ctrl-# ja meist, um mal eine Zeile oder Abschnitt schnell "raus zu schmeißen". Da wäre es umständlich, noch etwas an der Standardformatierung ändern zu müssen.

Dagegen ist es seltener (zumindest für mich), dass man erläuternden Kommentar schreibt.
Da man dort ohnehin etwas neues schreibt, kann man dort auch ein zusätzliches Zeichen einfügen.

Aber da kann man nochmal die sinnvollste Lösung abstimmen.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1449648)

Das finde ich problematisch, weil es schon einige Konventionen für Kommentar gint. MMX hat //1 und //2, PasDoc hat auch ein paar Konventionen. Wäre es nicht besser, den kommentierten Code extra zu kennzeichnen? Oder das konfigurierbar zu machen?

Insbesondere XMLDOC gibt hier schon von Delphi-Seite einen Standard vor: Kommentare in der XML-Dokumentation

[stahli]

Das habe ich schon dabei.

Der Kommentar wird mit dem Code bündig eingerückt und mehrere Leerzeichen nacheinander werden auf eins verkürzt.
Könnte ich noch ändern, falls nötig.

[stahli]

Hallo zusammen,

hier eine neue Testversion als Exe.
Links kann Code per C&P eingefügt werden und rechts erhält man wieder das formatierte Ergebnis.

Es sollten einige Verbesserungen zur ersten Version erkennbar sein, aber es kann natürlich noch Probleme geben.

Hier ein paar kurze Videos:

a) Allgemeines: https://youtu.be/jhB7eb4ci3Y
Der aktuelle Stand und einige Optionen.

b) Kommentarvarianten: https://youtu.be/zyiBAZMBQQA
Der Optimizer unterscheidet zwischen echten Komentaren (formatiert und unformatiert) und auskommentiertem Quelltext.
Wenn man den Optimizer nutzen möchte, sollte man unbedingt darauf achten, echte Kommentare entsprechend zu kennzeichnen.
Für den Compiler macht das dann keinen Unterschied aber für die Codedarstellung und Optimierung ist eine Unterscheidung wichtig.

c) spezielle Einrückungen: https://youtu.be/KdRK1-Yl5LQ
Der Optimizer unterstützt "Tabs", um bestimmte Codestellen untereinander auszurichten.
Beispielsweise werden Getter und Setter in Propertydeklarationen untereinander ausgerichtet.
Hier stellen sich eini9ge Detailfragen, wenn lange Bezeichner verwendet werden und Zeilen umgebrochen werden müssen.
Welche Regeln bzw. Optionen würdet Ihr diesbezüglich für sinnvoll halten?
Ähnliche Fragen ergeben sich bezüglich Fluent Interfaces. Was würdet Ihr das für sinnvolle Optionen halten?

d) Test-Runs: https://youtu.be/GyybXwaCKpk
Das ist eher etwas für mich und für Profis. ;-)
Man kann erfolgreich optimierte Units abspeichern und bei neueren Programmversionen testen, ob das als positiv festgestellte Ergebnis dann weiterhin erzielt wird.
Es ist etwas Bastelarbeit und erfordert ein externes Vergleichstool (z.B. Beyond Compare).
Wer den Optimizer einsetzen will und sicherstellen möchtem dass erzielte Optimierungen auch künftig noch erzielt werden, kann sich so einige Units ablegen um künftige Prüfungen durchführen zu können - im Sinne eriner Qualitätssicherung.
Grundsätzlich ist das jedoch eine Funktion für Entwickler des Tools.

e) Planung: https://youtu.be/w3973h1G0IE
Geplant ist ein kommerzielles Angebot und eine kostenfreie Version, jeweils als Formatierer zur Einbindung in Delphi.
Bis das bei mir stabil funktioniert werde ich aber aucvh gern weitere Versionen als externe Exe zur Verfügung stellen.

Ich würde mich über Rückinfos freuen, was Ihr vom derzeitigen Stand und den weiteren Aussichten haltet...

[stahli]

Sorry, da waren doch noch ein paar Fehler drin.
Ich hatte die Ergebnisse nur optisch geprüft und nicht beachtet, dass ich zuvor mit einem falschen Stand weiter gearbeitet hatte. :oops:

Also anbei eine aktualisierte Exe.

Ich habe jetzt auch schon zumindest 2 echte Units innerhalb Delphi formatieren lassen (Ctrl-Shift-O anstatt Ctrl-D), was wunderbar funktioniert hat.
Compilieren kann ich die Units wie zuvor und das Styling ist weitestgehend wie erhofft, aber im Detail muss ich mir das nochmal ansehen (bin allerdings ziemlich platt nach Durcharbeiten am Wochenende ;-) ).

Ich stelle Euch auch gern mal ein Package zur Einbindung als Delphi-Experten zur Verfügung, bin aber nicht sicher, was man dazu (ohne Quelltext) weiter geben muss.
Anbei mal eine Zip. Ich bin aber nicht sicher, ob die reicht (kompiliert für D 10.3.2. CE).

Natürlich solltet Ihr das Tool noch vorsichtig einsetzen.
Die Änderungen lassen sich mit Ctrl-Z rückgängig machen, aber es ist natürlich auch möglich, dass das Tool mal abstürzt oder sich aufhängt. Ist halt noch eine frühe Phase!
Ich werde es jetzt jedenfalls selbst regelmäßig benutzen und ständig verbessern...

Wenn jemand Interesse oder Tipps hat, dann gebt bescheid...

[stahli]

noch ein neuer Stand...
Es ist jetzt soweit, dass es schon ganz gut real einsetzbar ist.

Der ganze Komplex der Codevervollständigung fehlt noch.
Was jetzt enthalten ist, wird etwa die kostenfreie Codeformatierung sein (+/- einige Features).

Hat jemand das Tool mal als Experten eingebunden und getestet?

Jetzt werden Bookmarks und Breakpoints erhalten und ggf. mit dem Quelltext zusammen verschoben (auch später, wenn mal ganze Codeteile verschoben werden).

Das Zusammenklappen der erzeugten Getter&Setter-Regionen funktioniert noch unzuverlässig.
Das System habe ich noch nicht richtig verstanden. Hat da jemand Erfahrung und kann helfen?

Bin gespannt...

[stahli]

Hmm...

Also die Widerherstellung der Bookmarks und Breakpoints nach der Codeformatierung habe ich im Griff.
Auch das Zuklappen der "Getter+Setter"-Regionen funktioniert.

Allerdings sind die ToolsAPI aus meiner Sicht nicht sehr eingängig.

Eigentlich würde ich aber nach dem Formatieren schon gern die Regionen wieder so auf- und zugeklappt herstellen, wie sie vor der Formatierung waren.

Die besten Infos zum Thema habe ich hier gefunden:
https://parnassus.co/mysteries-ide-p...ed-elided-code
Allerdings übersteigt das meine Fähigkeiten und ist mir zu heikel, so etwas zu realisieren.

Weiß jemand evtl, wie die IDE die Informationen über auf- und zugeklappte Regionen speichert und diese wieder herstellt?

Wenn es keine machbare Lösung gibt, kann ich auch mit meiner bisherigen Lösung leben.
Eine komplette Wiederherstellung des vorherigen Standes wäre mir aber schon noch lieber.

[dummzeuch]

Ich habe in GExperts (insbesondere im Code-Formatter) mit Code-Folding / Unfolding herumexperimentiert, es aber irgend wann aufgegeben. Es ist den Aufwand einfach nicht wert (zumindest für mich persönlich).

Das Verschieben der Bookmarks und Breakpoints ist auch ziemlich aufwändig. Ich habe es einigermaßen hinbekommen, aber perfekt ist es definitiv nicht. Wenn das bei Dir besser klappt: Hut ab!

Die Einstellungen zum Code Folding werden anscheinend in der .dsk-Datei des Projekts gespeichert, und zwar im Eintrag "Elisions" des jeweiligen Views:

Code:

[View0]
CustomEditViewType=TEditView
Module=D:\source\test\Unit1.pas
CursorX=1
CursorY=9
TopLine=1
LeftCol=1
Elisions={{10,23},{15,6},{''}}
Bookmarks=
EditViewName=D:\source\test\Unit1.pas

Ob Dir das allerdings hilft, ist fraglich, denn die Datei wird anscheinend erst beim Schließen des Projekts aktualisiert.

[stahli]

Danke.

Ich könnte mir vorstellen, das Speichern und Laden der Regionen-Zustände nachzubauen und um den Aufbereitungsprozess zu setzen.

Aber es gibt da offenbar so viele unterschiedliche Module und Daten, die da zusammenspielen, dass das ziemlich unsicher wäre, alles stabil zu händeln.
Wenn es eine übersichtliche Zusammenfassung gäbe oder die Quelltexte einsehbar wären, würde ich das mal versuchen. So ist das aber wohl zu unübersichtlich. Haben andere offenbar auch schon so eingeschätzt.

Worauf basiert die Delphi-IDE eigentlich? Anscheinend gibt es da eine gemeinsame Basis zu Visual Studio und anderen Editoren. Jedenfalls landet man mit Suchbegriffen aus den ToolsAPI auch öfter bei MS und in anderen Bereichen.

[dummzeuch]

Zum Thema Teilformatierung:

Das kann man genauso implementieren wie die Positionen der Breakpoints:

1. Anfangs- und Endzeile der Markierung bestimmen
2. Marker setzen, die mit verschoben werden
3. Gesamten Text formatieren
4. Die beiden Marker suchen und die markierten Zeilen durch den formatierten Text dazwischen ersetzen

Das ist in GExperts so implementiert. Es funktioniert nicht perfekt, aber für mich gut genug.

[stahli]

Ja, ok, so wäre das machbar.

ABER:

1.) wäre trotzdem die gesamte Unit "bearbeitet" also wäre die gelbe Markierung links komplett über die gesamte Unit

2.) erkenne ich keinen Vorteil einer solchen teilweisen Formatierung. Schneller wäre es nicht und u.U. passt der Bereich dann nicht zum Umfeld, welches nicht "korrekt" formatiert wurde.

Wichtiger fände ich es statt dessen, genügend Optionen zur Verfügung zu stellen, so dass die Formatierung einer gesamten Unit akzeptiert und nicht als nachteilig empfunden wird.

NACHTRAG: Bezüglich fehlenden Ends usw. könnte ich mir vorstellen, an der Stelle einen Fehlerhinweis einzublenden und die Formatierung komplett zu verwerfen. Das habe ich aber noch nicht versucht umzusetzen...

Was mich aber in der aktuellen Arbeit stört, sind die Standardvorgaben von Delphi. Z.B. werden neue Zeilen und Anweisungen nach "Delphi-Regeln" erzeugt, die sich nicht zu "meinen Formatierungen" passen. Das sieht daher bei neuen Zeilen z.T. ziemlich wüst aus, bis ich dann Ctrl-Shift-O bzw. jetzt auch Ctrl-D drücke.

Cool wäre eine smarte Formatierung im Hintergrund, die den geschriebenen Text fließend optimiert, aber das wird mit Delphi nichts werden, denke ich.

[dummzeuch]

Zitat:

Zitat von stahli (Beitrag 1460481)

Ja, ok, so wäre das machbar.

ABER:

1.) wäre trotzdem die gesamte Unit "bearbeitet" also wäre die gelbe Markierung links komplett über die gesamte Unit

Wieso? Wenn Du nur die markierten Zeilen ersetzt und den Rest beibehältst, passiert das doch nicht.

Zitat:

Zitat von stahli (Beitrag 1460481)

2.) erkenne ich keinen Vorteil einer solchen teilweisen Formatierung. Schneller wäre es nicht und u.U. passt der Bereich dann nicht zum Umfeld, welches nicht "korrekt" formatiert wurde.

Aha, ein Purist. ;-)

Vorteil ist, dass man an einer Unit nur genau den Bereich ändert, den man bearbeitet hat. Ein Vergleich mit vorherigen Versionen der Unit (im SCM) zeigt also auch nur dort Änderungen.

Zitat:

Zitat von stahli (Beitrag 1460481)

Wichtiger fände ich es statt dessen, genügend Optionen zur Verfügung zu stellen, so dass die Formatierung einer gesamten Unit akzeptiert und nicht als nachteilig empfunden wird.

Es geht ja nicht darum, dass einem das neue Format gefällt, man will auch echte Änderungen erkennen können bzw. die Formatierung auf neuen bzw. geänderten Code beschränken. Der Rest soll unverändert bleiben.

Zitat:

Zitat von stahli (Beitrag 1460481)

Cool wäre eine smarte Formatierung im Hintergrund, die den geschriebenen Text fließend optimiert, aber das wird mit Delphi nichts werden, denke ich.

Ich glaube das würde mich wahnsinnig machen.

[stahli]

Ja, ok, ist auch nachvollziehbar (das mit der Teilformatierung, nicht mit der Smart-Formatierung ;-) ).

Mal sehen, ich schaue mir das später mal mit an...

[stahli]

Hier mal eine neue Testversion.

Die RichEdits mit dem alten und neuen Quelltext werden jetzt immer synchronisiert und auf Wunsch die Zeilen nummeriert: https://youtu.be/qH-kT2I5q6g

Als nächstes werde ich jetzt die Umsortierung des Implementationsteils angehen.

[stahli]

Hallo,

was haltet Ihr von einer Kennzeichnung der Klassen und ggf. Klassensektionen im Implementationsteil?

Die Klassendeklarationen werden entsprechend geordnet und in verschiedene Sektionen aufgeteilt.
Später erfolgen auch noch Unterteilungen nach eingebundenen Interfaces (z.B. "public //: IMyIntf" für die Properties und "protected //: IMyIntf" für die Getter und Setter).
Das macht der Optimizer alles automatisch und ist m.E. sehr übersichtlich.


Im Implementationsteil bin ich mir jedoch nicht so ganz sicher. Die Klassen so auffällig auszuzeichnen finde ich schon sinnvoll.
Aber bei den Sektionen sollten vielleicht nur die Interface-Sektionen explizit ausgezeichnet werden?
Sollte die Sortierung dann dort vielleicht sogar abweichend zur Interface-Deklaration sein?
Ich kann natürlich auch wieder mehrere Optionen anbieten.
Was würdet Ihr bevorzugen?


PS: Das standardmäßige "{ TMyClass }" der Delphi-IDE könnte automatisch umgewandelt werden. Das wäre technisch kein Problem.

[DasWolf]

Zitat:

Zitat von stahli (Beitrag 1461468)

Hallo,

was haltet Ihr von einer Kennzeichnung der Klassen und ggf. Klassensektionen im Implementationsteil?

Stichwort "Regionen".

Das zweite Bild ist echt grausam anzusehen.

[stahli]

Bei Zugriffrechten in Klassen wird von Abschnitten gesprochen. Daher hatte ich von Sektionen gesprochen.

Oder meinst Du, ich solle Regionen vorsehen, die man zuklappen kann?
Das fände ich unpraktisch, da man sich dann immer einen Wolf klappen müsste. ;-)


Optisch fand ich das auch im ersten Moment sehr hässlich. ABER:
Inzwischen finde ich das gar nicht so schlecht. Man hat quasi unmittelbar die Struktur der Klassendeklaration nochmal im Implementationsteil abgebildet und weiß ständig, wo man sich genau (auch mit welchen Zugriffsrechten) befindet.
Wenn man z.B. eine neue Prozedur in so einem gekennzeichneten Bereich schreibt, dann kann der Optimizer diese auch im passenden Bereich der Deklaration erzeugen. (Das könnte sogar bis in eine Interfacedeklaration weiter gereicht werden wenn man sich in einem "Interface-Abschnitt" befindet - ggf. auch erst nach Rückfrage).

Ich finde es inzwischen gar nicht mehr so sinnvoll, einen riesigen Implementationsteil mit jeder Menge Klassenimplementationen zu haben. Aber ist halt nun mal so Delphi, da kann man nix dran ändern.
Nun geht es darum, diesen Teil möglichst strukturiert zu gestalten (bzw. automatisiert gestalten zu lassen).

Man kann zwar das Codebeispiel optisch unschön finden, es aber dennoch (wie ich) für praktisch halten...

Oder man kann dem gar nichts abgewinnen oder man findet das sogar stylisch!?.
Fest gemeißelt ist ja noch gar nichts. Daher wollte ich gern Meinungen und Vorschläge einholen.
Vielleicht kristallisieren sich ja ein paar machbare und sinnvolle Varianten heraus...?

[stahli]

Mal eine neue Test-Exe.
Jetzt erkennt man die Verschiebungen der Blöcke, was ggf. die Übersichtlichkeit erhöht (wenn man die Änderungen einmal genauer nachvollziehen möchte).

Jetzt werde ich mich endlich mit der Klassenvervollständigung befassen können. :-)

[stahli]

Optimierung der Umbrüche bei mehreren Tabs in einer Zeile.
Jetzt werden alle gleichartigen Tabs eines Blockes identisch umgebrochen (im Beispiel alle "write" der zusammengehörigen Properties - auch wenn nur eines nicht auf eine Zeile passt).

[stahli]

Testversion5 - einige kleine Problemchen bereinigt

[stahli]

Hier mal einige Screenshots einiger neuer Formatierungen.

Die ersten 3 zeigen Ausrichtungen und Umbrüche an "Tabulatoren".
Getter und Setter werden z.B. auch untereinander ausgerichtet, wenn sie (vorläufig) auskommentiert sind. Wenn sie später gelöscht werden bleiben dort entsprechend Lücken bestehen.
Umbrüche z.B. von längeren Konstanten werden am "=" ausgerichtet.

Dann einige Beispiele von Ausrichtungen von ":=".
Das war ein Wunsch eines Testers und ich fand die Idee eigentlich fragwürdig - also habe nicht mit einem guten Ergebnis gerechnet.

Aber das gefällt mir jetzt RICHTIG GUT! :-)

Ich werde das also so oder so ähnlich selbst nutzen und als Option mit einbauen.
Mich würde mal interessieren, was Ihr dazu sagt...

(Dass vor begin, else usw. bzw. nach then keine Zeilenumbrüche existieren, soll hier mal nicht das Thema sein. Die Einrückungen wären dann natürlich entsprechend auch wie abgebildet möglich.)

[stahli]

Ich habe mal eine Einrückung von Fluent-Interfaces umgesetzt: https://youtu.be/EKxBDecttOU (5 Min).

Sagt mir doch mal bitte, was Ihr davon haltet (insbesondere @Mavarik).

Nutzt das jemand und haltet Ihr die Umsetzung für tauglich?


EDIT: Das Einrücken unterhalb von Punkten habe ich doch noch realisiert (zwei neue Screenshots).
Es kann natürlich Fälle geben, in denen die Einrückung zu weit nach rechts reicht... !?
... Dann geht aber auch der Umbruch am ersten Punkt (Bild3).

[stifflersmom]

Daumen hoch, mir gefallen die Formatierungen schon sehr gut.
Respekt!

[HeZa]

Hallo Stahli,

das sieht hübsch aus.

Ich würde so allerdings niemals formatieren.

Ändert man z.B. den Klassennamen der Klasse mit dem Fluentinterface, würden sich unter Umständen sehr viele Units ändern wenn man diese Art der Formatierung konsequent anwendet.

Das sieht in der Versionsverwaltung immer schlecht aus (zum Glück kann wenigstens BeyondCompare Whitespace-Unterschiede ausblenden).

Bei ausgerichteten Zuweisungen, muss man für das Suchen aller Zuweisungen einer Variablen schon mit RegEx arbeiten.

Bei mir wird alles mit zwei Leerzeichen eingerückt und Zuweisungen (:=) haben immer ein Leerzeichen hinter dem Variablennamen. Habe ich mir nach dem Lesen von CodeComplete vor ..., boah, sind das echt schon Jahrzehnte, angewöhnt.

Ciao HeZa