UnitOptimizer

[stahli]

Ich bin dabei, ein Tool aufzubauen, das Units sortiert und Code ergänzt.

Es ist quasi eine Klassenvervollständigung, Codeformatierung und Codesortierung in einem.

Hier mal ein aktueller Zwischenstand als Video: https://youtu.be/cfKa3wuoEd0

Eine direkte Codeformatierung (Einrückung) habe ich noch nicht drin, will das aber auch noch ergänzen. Die anderen Features gehen für mich aber vor.

Die Abkürzung "prop" könnte man auch mit "property" ausschreiben lassen. Ebenso sind optional andere Voreinstellungen möglich, wenn dies gewünscht würde. Ich bin zunächst erst einmal von meinen Wünschen ausgegangen.

Ich würde das später sehr gern kommerziell anbieten, wenn es Nachfrage gibt.
Für öffentliche Tests ist es noch etwas früh. Dazu muss ich noch einiges ausbauen und ausbessern.
Sofern jemand Erfahrungen mit den OTA hat und daran mitarbeiten möchte, dann gebt Bescheid...



Ich hatte dazu schon einen Thread, der sich aber speziell auf die Interface-Unterstützung bezogen hatte. Da das Tool aber Units allgemein bearbeitet habe ich hier einen neuen Thread eröffnet.

[KodeZwerg]

Hallo Stahli!

Erstmal bin ich etwas durcheinander mit dem was Du schreibt.

Zitat:

das Units sortiert

Wie meinst Du das, sortiert? Was wird da sortiert?

Zitat:

Code ergänzt

Noch mehr Fragezeichen, was genau passiert da?

Frage und Bitte,
da YouTube hier gesperrt ist, könntest Du Bitte zwei Bilder anfügen um Vorher -> Nachher effekt zu Demonstrieren?

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.

[stahli]

Vorher/Nachher ist schwierig, da man die gesamte Unit sehen muss.

Die Codevervollständigung ist m.E. umfangreicher und komfortabler als die von Delphi.
Man muss weniger schreiben und es wird mehr vervollständigt.
Auch Member benutzter Interfaces werden automatisch in Klassen übernommen.
Mal ein Beispiel einer einfachen Klasse:



Original:

Delphi-Quellcode:

unit Unit2;

interface

uses
  System.Classes, Vcl.Graphics, System.Types, System.UITypes;

const

  aConst = 100;

type

  TClass1 = class
  private
    procedure PrivProc; virtual;  
  public
    constructor Create; virtual;
    destructor Destroy; override;
  public
    procedure Execute(NewVal: String); virtual;
    function TestFunc(var Val1: Integer): Boolean;
    prop PropString: string;
    prop PropInteger: Integer rf wn;
    prop PropBoolean: Boolean rn vi pv;
    prop PropByte: Byte sc;
    prop PropWord: Word rf wn;
    prop PropString2: string pc vi;
  end;

implementation

end.

Ergebnis:

Delphi-Quellcode:

unit Unit2;

interface

uses
  System.Classes, Vcl.Graphics, System.Types, System.UITypes;

const

  aConst = 100;

type

  TClass1 = class
  private
    fPropString: string;
    fPropInteger: Integer;
    fPropBoolean: Boolean;
    fPropByte: Byte;
    fPropWord: Word;
    fPropString2: string;
    procedure PrivProc; virtual;
    function _get_PropString: string;
    procedure _set_PropString(aValue: string);
    procedure _set_PropBoolean(var aValue: Boolean); virtual;
    function _get_PropByte: Byte; stdcall;
    procedure _set_PropByte(aValue: Byte); stdcall;
    function _get_PropString2: string; virtual;
    procedure _set_PropString2(const aValue: string); virtual;
  public
    constructor Create; virtual;
    destructor Destroy; override;
    procedure Execute(NewVal: String); virtual;
    function TestFunc(var Val1: Integer) Boolean
    property PropString: string read _get_PropString write _set_PropString;
    property PropInteger: Integer read fPropInteger;
    property PropBoolean: Boolean write _set_PropBoolean;
    property PropByte: Byte read _get_PropByte write _set_PropByte;
    property PropWord: Word read fPropWord;
    property PropString2: string read _get_PropString2 write _set_PropString2;
  end;

implementation

{ TClass1 }

constructor TClass1.Create;
begin

end;

destructor TClass1.Destroy;
begin

end

procedure TClass1.PrivProc;
begin
  ?;
end

function TClass1._get_PropString: string;
begin
  Result := fPropString;
end

procedure TClass1._set_PropString(aValue: string);
begin
  if (fPropString <> aValue) then
  begin
    fPropString := aValue;
  end;
end

procedure TClass1._set_PropBoolean(var aValue: Boolean);
begin
  if (fPropBoolean <> aValue) then
  begin
    fPropBoolean := aValue;
  end;
end

function TClass1._get_PropByte: Byte;
begin
  Result := fPropByte;
end

procedure TClass1._set_PropByte(aValue: Byte);
begin
  if (fPropByte <> aValue) then
  begin
    fPropByte := aValue;
  end;
end

function TClass1._get_PropString2: string;
begin
  Result := fPropString2;
end

procedure TClass1._set_PropString2(const aValue: string);
begin
  if (fPropString2 <> aValue) then
  begin
    fPropString2 := aValue;
  end;
end

procedure TClass1.Execute(NewVal: String);
begin
  ?;
end

function TClass1.TestFunc(var Val1: Integer): Boolean;
begin
  Result := ?;
end

end.

Zur Interface-Unterstützung wäre noch mehr zu sagen. Da verweise ich mal auf den vorherigen Thread: https://www.delphipraxis.net/193733-...stuetzung.html bzw. auf das Video.



Weiterhin wird der Code im Implementationsteil so sortiert, wie er in den Klassendeklarationen angeordnet ist. Die Reihenfolge ist also oben wie unten immer identisch. (Ausnahme sind standardmäßig contructor und destructor, die im Implementationsteil immer als erstes kommen.)
Bei Umsortierungen und Formatierungen werden gesetzte Haltepunkte und Bookmarks im Code immer beibehalten.



Die Codeformatierung habe ich noch nicht umgesetzt.
Ich habe aber z.B. vor, verkettete Anweisungen zu berücksichtigen (wenn die neue Zeile mit einem Punkt beginnt und Methoden eines Objektes oder Interfaces aufrufen) und z.B. read und write von aufeinanderfolgenden Properties untereinander auszurichten.



Um das richtig einzuordnen, ist sicherlich sinnvoll, mal das Video anzuschauen.
Aus meiner Sicht löst das eigentlich genau das, was mir an Delphi schon lange auf die Nerven ging - abgesehen davon, dass es noch nicht ganz fertig ist. Daher bin ich überrascht, dass es da so wenig Resonanz gab bisher.

Ich dachte, es lag vielleicht an dem bisherigen Schwerpunkt auf Interfaces, so dass es die Leute vielleicht übersehen haben, die (noch) nicht mit Interfaces arbeiten. Daher der neue Thread.


PS: Einen Metadateneditor habe ich nicht vor. Da bringen aber aktuelle Delphi IDEs m.E. ja auch schon etwas mit.

[Uwe Raabe]

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.

Das gibt's schon: Documentation Insight

[KodeZwerg]

@stahli: Danke nochmal fürs Erklären was Du so vor hast, habs nun verstanden!:thumb:

ot

Zitat:

Zitat von Uwe Raabe (Beitrag 1402964)

Das gibt's schon: Documentation Insight

Danke, das was ich da sehe ist genau was ich wollte, nur ohne die Eigentliche Programm funktionalität. Vielleicht finde ich ja so etwas auch einzeln. Danke auf jedenfall für Antwort!
/ot

[himitsu]

Ein Documentation-Insight Embarcadero-Edition (Light-Variante) gab es für paar Jahre kostenlos in der IDE, aber der Herstelle wollte es nicht mehr, womit man es sich nun nur noch kaufen kann.

Einen Editor dafür gab es von Embarcadero noch nie ... nur den vom Documentation-Insight.
Es gibt aber schon immer die Code-Templates, auch wenn die nicht so "schön" intuitiv sind.

Im Delphi gibt es standardmäßig nur das Help-Insight, was ein Minimum an Funktionalität bietet. (das kann man durch das große Documentation-Insight ersetzen)

[Luckie]

Deine automatische Codevervollständigung erstellt Code, der sich nicht kompilieren lass. Hier zum Beispiel:

Delphi-Quellcode:

Result := ?;

. Das würde ich nicht machen. Zum einem leässt es sich nicht testweise kompilieren und zum anderen zeigt ErrorInsight dann immer Fehler an und man ist verwirrt, weil man an den Stellen ja noch nichts gemacht hat. Auch bringt das wohl manchmal den ErrorInsight durcheinander.

[stahli]

Ja, das stimmt, das ist aber auch nur eine erste Option, die ich hier umgesetzt habe.

Man könnte den Rumpf auch leer lassen oder ein DebugBreak einsetzen oder ein Assert oder was auch immer.
Individuell könnte sich das jeder in den Einstellungen auswählen oder selbst etwas vorgeben.

Worauf es mir mehr ankam sind die Dinge, die ja nahezu immer gleich laufen, also die Getter und Setter der Properties und die dortige Benutzung von privaten Feldern.
Gerade wenn man Interfaces benutzt ist es doch zu 99% immer das Gleiche:

Ich definiere ein Property MyProp: Integer;
Dann MUSS ich im Interface einen Getter und Setter zuordnen (wenn das Proprty lesbar und beschreibbar sein soll).
Und ich MUSS in jeder Klasse, die das Interface benutzt, immer wieder den selben Kram ausschreiben.
Lasse ich Getter und Setter halbwegs automatisch erzeugen, werden die im Implementationsteil IRGENDWO erzeugt. Wenn mir Ordnung wichtig ist, muss ich die in der Unit verschieben. Die privaten Felder muss ich dann auch noch erzeugen und Getter und Setter ausprogrammieren.

Verzichte ich wegen dem inzwischen hohen Nervfaktor auf korrekte Einrückungen und lasse nachher den Codeformatierer drüber laufen sind die Haltepunkte der Unit weg.

Das alles soll mein Tool vereinfachen.
So kleine Details, die jeder vielleicht etwas anders haben möchte, kann man ja über Optionen individuell einstellbar machen.

Die Fragezeichen könnte man jetzt auch als Platzhalter sehen. Das muss nicht so bleiben. Ist ja auch noch nicht fertig.


PS: Den MMX hatte ich mir auch angesehen, aber das war nicht das, was ich gesucht hatte. Da finde ich eine Lösung über einen Hotkey besser. Da es nichts fertiges gab, habe ich mich mal dran versucht.

[himitsu]

Zitat:

Ich definiere ein Property MyProp: Integer;
Dann MUSS ich im Interface einen Getter und Setter zuordnen (wenn das Proprty lesbar und beschreibbar sein soll).
Und ich MUSS in jeder Klasse, die das Interface benutzt, immer wieder den selben Kram ausschreiben.
Lasse ich Getter und Setter halbwegs automatisch erzeugen, werden die im Implementationsteil IRGENDWO erzeugt. Wenn mir Ordnung wichtig ist, muss ich die in der Unit verschieben. Die privaten Felder muss ich dann auch noch erzeugen und Getter und Setter ausprogrammieren.

Die Live-Code-Templates ala prop, propf, propgs, propro und proprof kennst du aber schon?

Ich glaub Daniel hatte mal vor Jaaaaaahren zu sowas noch paaar noch inteligentere Varianten gebastelt/gezeigt.

[Luckie]

OK. Also war es erst mal nur eine vorläufige Umsetzung. Dann ist alles gut. ;)

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1402982)

Die Live-Code-Templates ala prop, propf, propgs, propro und proprof kennst du aber schon?

Ich glaub Daniel hatte mal vor Jaaaaaahren zu sowas noch paaar noch inteligentere Varianten gebastelt/gezeigt.

Die Templates errichten aber doch keinen kompletten verteilten Unit-Code - oder?
Wenn es so etwas gäbe würde mich ärgern, mich damit aufgehalten zu haben. Aber mir ist nicht bekannt, dass es etwas gäbe, was da in etwa gleiches umsetzen würde (auch immer mit ausgehend von Deklarationen in Interfaces, die automatisch auch in Klassen übernommen und mit Standardcode ausgefüllt werden und eine Sortierung der Unit durchführt).

[himitsu]

Diese Live-Templates machen alles Mögliche, sogar schon die Standardtemplates von Embarcadero.

Die erstellen das Property und das nötigen/fehlende Feld/Variable, sowie die Getter- und Setter-Methoden, inkl. der Zuweisung zwischen Feld/Parameter/Result.
Und z.B. das FOR-Template erstellt auch die lokale Variable, wenn es sie noch nicht gab.

Templates reichen von einfachen Text-Vorlagen bis hin zu kleinen/größeren Scripten (quasi Miniprogramme).

[stahli]

Dann muss ich mir das heute Abend mal genauer anschauen. Ich bin aber skeptisch, dass mir das umfangreich genug ist.

[himitsu]

Das liese sich ja notfalls anpassen/erweitern :)

[stahli]

Also ich konnte es jetzt testen und finde es untauglich - oder allenfalls minimal hilfreich.
Wenn es erweiterbar wäre hätte es ja schon mal jemand machen können.

Nun gut, mein Tool macht bestimmt mehr, als eine solche Erweiterung wohl erreichen könnte.

Also ist mein Tool für mich der richtige Ansatz (wenngleich es noch nicht ganz fertig ist).

[stahli]

Hier mal ein kleiner Einblick in die reale Verwendung:
https://youtu.be/q7X_gxcz12I (4 min)

Ist noch nicht ganz fertig, aber grundsätzlich ist das genau, was ich wollte. :-)

Ich möchte das später mal kommerziell anbieten, falls es jemand aber mal testen möchte, bitte pm.


PS: Vielen Dank an Uwe für die Hilfe!

[KodeZwerg]

Würde Dein UnitOptimizer auch Namespace ergänzen bzw entfernen / Je nach verwendeter Delphi Version?

[stahli]

Nein, der Optimizer ändert aktuell nichts an den uses-Klauseln.

Wenn ich entsprechendes regeln sollte müsste ich erst mal wissen, was Du ganz konkret meinst.

[KodeZwerg]

Beispiel:
Ich lade mit meinem alten Delphi ein von der Sache her kompatibles Projekt rein, was aber diese Namespaces verwendent Winapi.Windows lautet bei mir nur Windows, Vcl.Forms bei mir nur Forms usw usf.

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1411708)

Beispiel:
Ich lade mit meinem alten Delphi ein von der Sache her kompatibles Projekt rein, was aber diese Namespaces verwendent Winapi.Windows lautet bei mir nur Windows, Vcl.Forms bei mir nur Forms usw usf.

Der MMX Code Explorer hat dieses Feature, allerdings nur in eine Richtung (Ergänzung der Unit-Namespaces). Soweit ich weiß, kann GExperts aber auch den umgekehrten Weg. Ich selbst sehe allerdings keine Notwendigkeit für diesen Rückweg, da ich grundsätzlich nur nach vorne portiere.

[stahli]

Einen Automatismus kann ich mir da nicht vorstellen.

Was möglich wäre, man könnte Wertepaare einrichten:

Zitat:

Winapi.Windows<->Windows
Vcl.Forms<->Forms

Mit einem Hotkey könnte man alle Units in uses-Klauseln umswitchen.

Man könnte das auch noch weiter ausbauen:

Zitat:

Winapi.Windows{VCL}<->Windows{old}
Vcl.Forms{VCL}<->Forms{old}<->FMX.Forms{FMX}

Nach Wahl eines Hotkeys wird eine Auswahl
VCL
old
FMX
angezeigt und man kann eines davon anwählen.
Alle Unit-Versionen in den uses-Klauseln würden dann durch die entsprechende Variante ersetzt werden.
Man müsste halt einmal entsprechende Paarungen definieren.

Das war nicht das Ziel meines Optimizers aber eine solche Lösung wäre mit umsetzbar.

[KodeZwerg]

Zitat:

Zitat von Uwe Raabe (Beitrag 1411710)

Soweit ich weiß, kann GExperts aber auch den umgekehrten Weg. Ich selbst sehe allerdings keine Notwendigkeit für diesen Rückweg, da ich grundsätzlich nur nach vorne portiere.

Das teste ich gleich mal, anscheinend genau zur Richtigen Zeit das es eine sehr aktuelle Version gibt: 2018-08-05

Danke für diesen Hinweis! :thumb:

[Delphi.Narium]

Zitat:

Zitat von stahli (Beitrag 1411711)

Einen Automatismus kann ich mir da nicht vorstellen.

Doch, eigentlich schon. Alte Delphis erlauben keinen Punkt im Namen einer Unit.
Wenn es also im Uses Unitnamen mit Punkt gibt, jeweils alles vor bis einschließlich letztem Punkt entfernen.

[KodeZwerg]

Also mein Delphi 7 konnte auch mit Punkt im Unit Namen! Delphi 2009 auch!

edit
Beispiel:
Dieses mini Sample von Schokohase zum Beispiel, ich musste halt nur von original Delphi Units den Namespace entfernen, die selfmade Units habe ich vom Namen her mit Punkt drinnen behalten.

Also ein "entferne alles was nen Punkt besitzt" wäre da fatal.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1411713)

Alte Delphis erlauben keinen Punkt im Namen einer Unit.

Generics.Collections
Generics.Defaults

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1411711)

Einen Automatismus kann ich mir da nicht vorstellen.

Im MMX Code Explorer werden zunächst anhand der Werte in den Projekt-Optionen alle Unit Aliase aufgelöst und daraus resultierende Doubletten entfernt (z.B. WinTypes, WinProcs). Dann wird für jede Unit in der so bereinigten Uses-Clause im Suchpfad/Bibliothekspfad gesucht. Falls nicht gefunden, werden sämtliche angegebenen Unit-Namespaces probiert bis einer passt. Der umgekehrte Weg könnte ähnlich laufen.

[raller09]

Moin,

ich habe mir die Funktion zum Erweitern der "Ergänzung des Unit-Namespace" sowohl in MMX wie auch in GEExperts angesehen. Super Funktion + scheint gut zu funktionieren!


https://www.uweraabe.de/Blog/2018/05...eature-in-mmx/
https://blog.dummzeuch.de/2018/08/04...r-in-gexperts/


Gibt es in einem der beiden Programmen die Funktionalität, das "für alle Dateien des Projektes" oder "für ein Verzeichnis" oder "für eine Liste von Dateien" gleichzeitig aufzurufen?


Ich möchte mal testen, ob diese Auflösung Einfluss auf die Kompilierungs-Geschwindigkeit in unserem Projekt hat ...
Sonst muss ich mich mal durch einige Dateien (> 500) klicken...


Danke,

[dummzeuch]

Zitat:

Zitat von raller09 (Beitrag 1412547)

ich habe mir die Funktion zum Erweitern der "Ergänzung des Unit-Namespace" sowohl in MMX wie auch in GEExperts angesehen. Super Funktion + scheint gut zu funktionieren!

Gibt es in einem der beiden Programmen die Funktionalität, das "für alle Dateien des Projektes" oder "für ein Verzeichnis" oder "für eine Liste von Dateien" gleichzeitig aufzurufen?

Für GExperts will ich das gerade nicht implementieren, da die Gefahr, sich dabei das komplette Projekt zu zerschießen ziemlich hoch ist.

Du kannst das aber gerne selbst tun, der Source ist ja verfügbar.

twm

[Uwe Raabe]

Zitat:

Zitat von raller09 (Beitrag 1412547)

Gibt es in einem der beiden Programmen die Funktionalität, das "für alle Dateien des Projektes" oder "für ein Verzeichnis" oder "für eine Liste von Dateien" gleichzeitig aufzurufen?

Es gibt eine Kommandozeilenversion, mit der das alles angefangen hat. Die ist eigentlich nicht für die Veröffentlichung aufbereitet und einiges ist da sicher noch verbesserungsfähig. Also alles ohne Gewähr.

Die Konfigurationsdatei solltest du auf dein Projekt anpassen (insbesondere den Suchpfad und die GroupNames) und mit dem -c Parameter auf der Kommandozeile übergeben. Das könnte dann in etwa so aussehen:

Code:

UsesCleaner -c:"c:\MyProjectPath\UsesCleaner.cfg" "c:\MyProjectPath\*.pas"

Es können auch mehrere Wildcard-Ausdrücke angegeben werden und wenn du noch einen Parameter -s spendierst, werden auch Unterverzeichnisse durchsucht.

[raller09]

Moin,

vielen Dank für die Rückmeldung.

Zitat:

Zitat von dummzeuch (Beitrag 1412548)

Für GExperts will ich das gerade nicht implementieren, da die Gefahr, sich dabei das komplette Projekt zu zerschießen ziemlich hoch ist.
Du kannst das aber gerne selbst tun, der Source ist ja verfügbar.

wollte ich im ersten Schritt vermeiden, aber kann ich mir ggf. ansehen.

Die angesprochen Probleme habe ich gerade auch mit der Sortierung der uses + der Funktion von Herrn Raabe aus MMX schon festgestellt:

Die dort eingestellte Sortierungs-Reihenfolge der Uses sorgt z.B. für einen Parameter-Fehler in "DeleteFile", da "PWideChar <> TFileName"

Ich hatte implizit System.SysUtils.DeleteFile genutzt, welches durch die geänderte Uses zu "Winapi.Windows.DeleteFile" wurde...

Wie war noch mal die Reihenfolge bei gleichen Funktions/Prozedur-Namen in verschiedenen Units. Ich meine Uses von unten nach oben, korrekt?


In welcher Reihenfolge werden die Namespaces Aufgelöst? Ich würde von links nach rechts tippen, ist das korrekt?

Zitat:

Zitat von Uwe Raabe (Beitrag 1412554)

Es gibt eine Kommandozeilenversion, mit der das alles angefangen hat. Die ist eigentlich nicht für die Veröffentlichung aufbereitet und einiges ist da sicher noch verbesserungsfähig. Also alles ohne Gewähr.

Vielen Dank für das Tool, damit teste ich mal. Ich werde die Sortier-Reihenfolge + Gültigkeitsbereichsnamen gleich meiner Projekt-Einstellung setzen.

Ich werde mir das bis zum Wochenende mal mit unserem Programm angesehen haben + gebe dann eine Rückmeldung.


Danke,

[raller09]

So, hab jetzt mal das Haupt-Verzeichnis der Units mit dem Tool von Herrn Raabe bearbeitet (350 Units).

"UnitScopeNames" so eingestellt wie im Projekt, "GroupNames=" (leer).

Dadurch wird nicht sortiert sondern nur entsprechend erweitert.
Ich musste noch an ein paar Stellen den fehlenden Scope vor einzelnen Funktions-Aufrufen erweitern...


Sieht soweit gut aus aber kompiliert leider auch nicht schneller (Erzeugen ohne IDEFixPack ca. 15 Min, mit ca. 3 Min.).
Lasse es aber trotzdem so. vielleicht bemerke ich noch Vorteile an anderer Stelle...


Danke

[stahli]

Ich habe jetzt die Formatierung angefangen.
Aktuell sehen die uses- und const-Abschnitte schon ganz gut aus. :-)

Es werden bestimmte Regeln zu den Einrückungen und Leerzeichen um bestimmte Zeichen eingehalten.

Die Einrückungen können auch bestimmte Inhalte (z.B. '=' oder später 'read' und 'write' von Properties) untereinander ausrichten.
Leerzeilen dienen dabei als Trennzeilen für einzelne Blöcke.

Umgebrochene lange Zeilen können ebenfalls an bestimmten Textmarken ausgerichtet werden.

Es gibt natürlich extrem viele Möglichkeiten, die da relevant werden können. Sicherlich hat da jeder Entwickler auch eigene Wünsche und Vorstellungen.
Mal sehen, wie weit ich damit komme.

Es ist auf jeden Fall eine ziemlich komplexe Angelegenheit. :-/


Was mir besonderes Kopfzerbrechen macht, ist der Umgang mit Zeilenumbrüchen und Kommentartexten.
Ich kann leider nicht unterscheiden, ob ein Zeilenumbruch durch einen Entwickler eingefügt wurde oder durch eine frühere Formatierung.
Entsprechend weiß ich bei einer Neuformatierung nicht, ob ein Zeilenumbruch bestehen bleiben soll oder ob der nach einer Codeänderung neu berechnet werden muss.
Workarounds, die mir da einfallen, sind nicht wirklich tauglich oder zumindest im Codeeditor störend. :-(
Weiß jemand, ob der Codeeditor sowas wie weiche Umbrüche unterstützt (Shift+Enter)? Ich habe leider noch nichts gefunden.

Bei Kommentaren werde ich unterscheiden zwischen "Auskommentierungen" und "echtem Kommentar". "Auskommentierungen" werden auf Wunsch wie Quelltext formatiert, was die Einrückungen, Umbrüche und Space-Korrekturen betrifft. Die Codezeilen werden dann zwischen begin-end usw. entsprechend eingerückt.
Echter Kommentar wird im Block wie gehabt linksbündig ausgerichtet und kann beliebige Leerzeichen enthalten.
(Für den Compiler bleibt natürlich alles normaler Kommentar.)


Anbei mal zwei Darstellungen eines Beispielcodes, unformatiert und formatiert.
Da das hier in der DP nur näherungsweise darstellbar ist, auch mal noch zwei entsprechende Screenshots.


VORHER:

Code:

unit uInterfaces;

interface

uses
  System.Classes,Generics.Collections         ,System.Generics.Collections   ,    Vcl.Graphics;

const
  sid_UnitFile = '{3D27E420-B68B-423D-8F4A-BF9179A14BF3}';
sid_Parser='{683E78A3-A24F-4841-81B2-459EC0A9A20F}';

  sid_ResultText = '{23B6DE22-7C2C-4F6C-BB49-F6BD5FCF9A56}'   ;
  sid_PosMarker = '{7F1F73C8-722E-4D87-A367-D06EFFA1D81E}'    ;
  sid_Word = '{CF738D99-C813-471B-9810-DD8BE204F007}'         ;
  sid_Words = '{A5461E5E-67A7-42EC-B918-23828C749DAA}'        ;

  sid_LB = '{3765F016-9575-4916-BDC4-CF0700462E0D}'           ;
  sid_Apostroph = '{904BD8A1-2149-4679-B80D-FC89CDFB31D7}';
  sid_Comment = '{AF8075A3-3C80-40DE-8963-53FC9A791B1D}';
  sid_CommentParenthesisStars = '{B0D4E9FB-BBF3-4C13-889F-21A54E54D70F}';
  sid_CommentCurlyBraces = '{2D28310E-F09F-4016-9D35-84DE5352F18A}';
  sid_CommentDoubleSlashes = '{C983F5E9-F68A-46D4-9895-AF68A38A0B04}';
  sid_CommentHK = '{FD36117E-5E4F-4D13-8D33-5407259F61A0}';
  sid_Attribute = '{2D28DE78-CD7A-4164-915D-BE4A228DFEAD}';
  sid_Type = '{40D018C6-55EC-4040-804C-5F45AEB77382}';
  sid_FoundMember = '{6E68F02E-2FB5-4FE2-BD53-1E8E5CFE3DF8}';
  sid_Unit = '{E7E7399C-AA72-472C-BD51-0EB6298FCB9B}';
  sid_UnitInterface = '{42207023-90C8-4D10-9066-F51221D8C53D}';
  sid_UnitImplementation = '{546D8E44-433C-46BF-96AB-3E6BDE4D4F09}';
  sid_UnitUses = '{AF8CD130-CB09-4D7D-AD26-FE2C636F9DBD}';
  sid_UnitUse = '{48EC2F39-887A-4AC5-893E-02B4B385B18F}';
  sid_UnitConst = '{64264236-FCAA-4765-896E-941DE00B8A59}';
  sid_UnitType = '{66906CF4-9489-4AD9-8246-FC2F010DAF4B}';
  sid_UnitInitialization = '{72DF6782-D73C-4353-8177-66BE26E3527E}';
  sid_UnitFinalization = '{CF5EAA57-9946-4875-91A6-75985DAFA2EB}';
  sid_ParamPart = '{8A3310C3-2126-4E85-8451-B2383FFF7D93}';
  sid_Params = '{04D95874-A9D6-475E-B9EA-CF2806108E29}';
  sid_Index = '{AFCF6127-F72A-472B-A963-25B3F3CCB365}';
  sid_Bases = '{FF65E2E6-BA17-444A-8F16-040EFD73B2B0}';
  sid_InterfaceClassDeclaration = '{604DD7AF-9699-4DF6-B333-EE49ACE67DB5}';
  sid_InterfaceDeclaration = '{2B986919-AF9E-4673-845B-001EBFD17E91}';
  sid_ClassDeclaration = '{61B14F2F-8B38-4995-A0A4-DDE4D70254D4}';
  sid_ClassSection = '{87176506-56B6-426F-BFCC-6DA956AB5560}';
  sid_Getter = '{15E251BF-A12A-480B-A512-07A7CA9B056D}';
  sid_Setter = '{E319417C-8AF6-4558-81DD-7F2970380C8E}';
  sid_ConstructorDeclaration = '{3CA6DA10-29B3-4393-AE41-FF8C7484232A}';
  sid_DestructorDeclaration = '{C1981961-EED7-45C4-9BBA-6F7E51597892}';
  sid_ProcedureDeclaration = '{C4DD75FD-138D-45D7-9C01-0928747CAFB9}';
  sid_FunctionDeclaration = '{D8F6BC30-5D06-4482-8C83-07ABC6EDD4F4}';
  sid_PropertyDeclaration = '{0294DE48-6390-4DE7-A4CD-EE17F62DA292}';
  sid_PropDeclaration = '{831497FE-1FA7-4418-B019-A505906D00E3}';
  sid_PropSig = '{919A50FC-A5A1-4464-98A3-D15F9778AD75}';
  sid_FieldDeclaration = '{6C62B581-CFAD-42CD-843D-6F9051BD16D7}';

  sid_ClassHeader = '{ADC0E9DF-803C-41AE-8CA4-1E2473144525}';
  sid_ClassConstructor = '{AAA34D34-E4DB-4BD1-A5C8-F27CDAF68E31}';
  sid_ClassDestructor = '{263AE578-4E0B-4093-9FC0-7264F619A98D}';
  sid_ClassProcedure = '{8D8585FA-B120-476B-B84B-46D29E2F8E4E}';
  sid_ClassFunction = '{F8A6A860-9B8E-4051-A533-D22ACDFAA510}';

TEST_Integer=1+2+3+4+5+6+7+8+9+11+2+3+4+5+6+7+888+9+1+2+3+44+5+6+7+8+9+1111+2+3+4+5+6+7+8+9+1+2+3+4+5+666+7+8+99999999999999999+11111+2+3+4+5+6+7+8+99+1+2+3+4+5+6+7+8+9+111+2+3+4+5+66+7+8+999;
Test_String='Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test '+'Test';

NACHHER:

Code:

unit uInterfaces;

interface

uses
  System.Classes, Generics.Collections, System.Generics.Collections, Vcl.Graphics;

const
  sid_UnitFile = '{3D27E420-B68B-423D-8F4A-BF9179A14BF3}';
  sid_Parser   = '{683E78A3-A24F-4841-81B2-459EC0A9A20F}';

  sid_ResultText = '{23B6DE22-7C2C-4F6C-BB49-F6BD5FCF9A56}';
  sid_PosMarker  = '{7F1F73C8-722E-4D87-A367-D06EFFA1D81E}';
  sid_Word       = '{CF738D99-C813-471B-9810-DD8BE204F007}';
  sid_Words      = '{A5461E5E-67A7-42EC-B918-23828C749DAA}';

  sid_LB                        = '{3765F016-9575-4916-BDC4-CF0700462E0D}';
  sid_Apostroph                 = '{904BD8A1-2149-4679-B80D-FC89CDFB31D7}';
  sid_Comment                   = '{AF8075A3-3C80-40DE-8963-53FC9A791B1D}';
  sid_CommentParenthesisStars   = '{B0D4E9FB-BBF3-4C13-889F-21A54E54D70F}';
  sid_CommentCurlyBraces        = '{2D28310E-F09F-4016-9D35-84DE5352F18A}';
  sid_CommentDoubleSlashes      = '{C983F5E9-F68A-46D4-9895-AF68A38A0B04}';
  sid_CommentHK                 = '{FD36117E-5E4F-4D13-8D33-5407259F61A0}';
  sid_Attribute                 = '{2D28DE78-CD7A-4164-915D-BE4A228DFEAD}';
  sid_Type                      = '{40D018C6-55EC-4040-804C-5F45AEB77382}';
  sid_FoundMember               = '{6E68F02E-2FB5-4FE2-BD53-1E8E5CFE3DF8}';
  sid_Unit                      = '{E7E7399C-AA72-472C-BD51-0EB6298FCB9B}';
  sid_UnitInterface             = '{42207023-90C8-4D10-9066-F51221D8C53D}';
  sid_UnitImplementation        = '{546D8E44-433C-46BF-96AB-3E6BDE4D4F09}';
  sid_UnitUses                  = '{AF8CD130-CB09-4D7D-AD26-FE2C636F9DBD}';
  sid_UnitUse                   = '{48EC2F39-887A-4AC5-893E-02B4B385B18F}';
  sid_UnitConst                 = '{64264236-FCAA-4765-896E-941DE00B8A59}';
  sid_UnitType                  = '{66906CF4-9489-4AD9-8246-FC2F010DAF4B}';
  sid_UnitInitialization        = '{72DF6782-D73C-4353-8177-66BE26E3527E}';
  sid_UnitFinalization          = '{CF5EAA57-9946-4875-91A6-75985DAFA2EB}';
  sid_ParamPart                 = '{8A3310C3-2126-4E85-8451-B2383FFF7D93}';
  sid_Params                    = '{04D95874-A9D6-475E-B9EA-CF2806108E29}';
  sid_Index                     = '{AFCF6127-F72A-472B-A963-25B3F3CCB365}';
  sid_Bases                     = '{FF65E2E6-BA17-444A-8F16-040EFD73B2B0}';
  sid_InterfaceClassDeclaration = '{604DD7AF-9699-4DF6-B333-EE49ACE67DB5}';
  sid_InterfaceDeclaration      = '{2B986919-AF9E-4673-845B-001EBFD17E91}';
  sid_ClassDeclaration          = '{61B14F2F-8B38-4995-A0A4-DDE4D70254D4}';
  sid_ClassSection              = '{87176506-56B6-426F-BFCC-6DA956AB5560}';
  sid_Getter                    = '{15E251BF-A12A-480B-A512-07A7CA9B056D}';
  sid_Setter                    = '{E319417C-8AF6-4558-81DD-7F2970380C8E}';
  sid_ConstructorDeclaration    = '{3CA6DA10-29B3-4393-AE41-FF8C7484232A}';
  sid_DestructorDeclaration     = '{C1981961-EED7-45C4-9BBA-6F7E51597892}';
  sid_ProcedureDeclaration      = '{C4DD75FD-138D-45D7-9C01-0928747CAFB9}';
  sid_FunctionDeclaration       = '{D8F6BC30-5D06-4482-8C83-07ABC6EDD4F4}';
  sid_PropertyDeclaration       = '{0294DE48-6390-4DE7-A4CD-EE17F62DA292}';
  sid_PropDeclaration           = '{831497FE-1FA7-4418-B019-A505906D00E3}';
  sid_PropSig                   = '{919A50FC-A5A1-4464-98A3-D15F9778AD75}';
  sid_FieldDeclaration          = '{6C62B581-CFAD-42CD-843D-6F9051BD16D7}';

  sid_ClassHeader      = '{ADC0E9DF-803C-41AE-8CA4-1E2473144525}';
  sid_ClassConstructor = '{AAA34D34-E4DB-4BD1-A5C8-F27CDAF68E31}';
  sid_ClassDestructor  = '{263AE578-4E0B-4093-9FC0-7264F619A98D}';
  sid_ClassProcedure   = '{8D8585FA-B120-476B-B84B-46D29E2F8E4E}';
  sid_ClassFunction    = '{F8A6A860-9B8E-4051-A533-D22ACDFAA510}';

  TEST_Integer = 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 11 + 2 + 3 + 4 + 5 + 6 + 7 + 888 + 9 + 1 + 2 + 3 + 44 + 5 + 6 + 7 +
                 8 + 9 + 1111 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 1 + 2 + 3 + 4 + 5 + 666 + 7 + 8 + 99999999999999999 +
                 11111 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 99 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 111 + 2 + 3 + 4 + 5 + 66 +
                 7 + 8 + 999;
  Test_String  = 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' +
                 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test ' + 'Test';

[EWeiss]

Sieht gut aus und gefällt mir.
Vor allem die Sortierung der sid_

Das jedoch fällt etwas aus dem Rahmen "sid_InterfaceClassDeclaration"
Es ist der längste string sollten dann nicht die anderen alle noch um 1 aufrücken?

Das scheint bei allen längsten srings zu sein.

gruss

[KodeZwerg]

Zitat:

Zitat von EWeiss (Beitrag 1417080)

Das jedoch fällt etwas aus dem Rahmen "sid_InterfaceClassDeclaration"
Es ist der längste string sollten dann nicht die anderen alle noch um 1 aufrücken?

Zitat:

Zitat von stahli (Beitrag 1417066)

Da das hier in der DP nur näherungsweise darstellbar ist, auch mal noch zwei entsprechende Screenshots.

Aufm Bild passt alles und ich kann auch nur meinen Respekt zollen indem ich sage: Das hast Du echt cool hinbekommen!

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1417085)

Zitat:

Zitat von EWeiss (Beitrag 1417080)

Das jedoch fällt etwas aus dem Rahmen "sid_InterfaceClassDeclaration"
Es ist der längste string sollten dann nicht die anderen alle noch um 1 aufrücken?

Zitat:

Zitat von stahli (Beitrag 1417066)

Da das hier in der DP nur näherungsweise darstellbar ist, auch mal noch zwei entsprechende Screenshots.

Aufm Bild passt alles und ich kann auch nur meinen Respekt zollen indem ich sage: Das hast Du echt cool hinbekommen!

Korrekt ;)
Macht wohl der Formater im Forum Trouble..
Nehme alles zurück :)

gruss

[generic]

Bezüglich des Uses kann ich nur empfehlen jede Unit untereinander zu schreiben,
dann klappt das mit den SVN/GIT besser beim Mergen.

[stahli]

Danke Euch, ist aber noch ein weiter Weg.

Bezüglich des weichen Umbruchs werde ich mal mit #00#0A#0D experimentieren oder mit #0A oder #0D statt #0A#0D.
Mal sehen, was Delphi da im Editor und Parser toleriert...
Es wäre halt schön, erkennen zu können, welche Umbrüche vom Optimizer eingefügt wurden.
Ich könnte da auch optional verschiedene Varianten ermöglichen, für den Fall, dass bestimmte Kennzeichnungen (in bestimmten Delphi-IDEs) Probleme machen sollten.

@generic
Da sehe ich auch gar kein Problem, das optional anzubieten.
Man hätte dann für die einzelnen Code-Abschnitte die Möglichkeit, bestimmte Vorgaben auszuwählen (für den uses-Block dann "OneUnitPerLine").

[EWeiss]

Zitat:

Da sehe ich auch gar kein Problem, das optional anzubieten.
Man hätte dann für die einzelnen Code-Abschnitte die Möglichkeit, bestimmte Vorgaben auszuwählen (für den uses-Block dann "OneUnitPerLine").

Ich habe ja nicht zu sagen.. aber ich würde mir einen Formater wünschen bei dem man nicht zu viele Einstellmöglichkeiten hat.
In die IDE einbinden - Formatieren klicken fertig!

Anschließend das Ergebnis wie bei dir in den Bildern. :)
Vollkommen ausreichend.

Funktionen, Proceduren Alphabetisch anordnen für jede Classe einzeln.
Das war's einfach, simple, schnell. (Ich meine natürlich die Bedienbarkeit)

gruss

[stahli]

Na ja, wer mit den Standardeinstellungen leben kann, muss ja keine Optionen ändern.

Eine alphabetische Funktionssortierung hatte ich allerdings nicht vorgesehen. Statt dessen soll sich standardmäßig der Implementationsteil immer nach der Reihenfolge in der Klassendeklaration richten.

Wenn dies abweichend alphabetisch sein soll, müsste ich eine Option zur Auswahl anbieten (und man müsste klären, ob in den Klassensektionen (private, public etc.) oder nur im Implementationsteil sortiert werden soll - wie es jetzt annähernd die IDE macht). ;-)

[EWeiss]

Zitat:

Eine alphabetische Funktionssortierung hatte ich allerdings nicht vorgesehen

In der Structur Ansicht sind die Funktionen Alphabetisch sortiert da bietet sich es doch an das auch im Code so zu handhaben.
Ich habe ja einen Formatierter jcf_243 aber genau hier liegt das Problem zuviele Einstellmöglichkeiten die einen fast erschlagen.

Da bleibe ich dann doch lieber bei dem in der IDE integrierten und nehme das was ich habe. Tabweite 4 und gut ist.
Alles andere bleibt wie es ist.

gruss