UnitOptimizer

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