UnitOptimizer

[stahli Online]

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 ///<summary></summary> oder ///<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 von KodeZwerg:

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 ///<summary></summary> oder ///<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!

ot

Zitat von Uwe Raabe:

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