UnitOptimizer

[Harry Stahl]

Zitat:

Zitat von dummzeuch (Beitrag 1464142)

Zitat:

Zitat von stahli (Beitrag 1464132)

Die testfile_LargeFile.pas braucht 13 Sekunden. 27.000 Zeilen in einer Unit sind ja aber sicherlich auch eher ungewöhnlich.

Zitat:

Zitat von stahli (Beitrag 1464132)

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht

Hier, wo der Finger leuchtet! Ich halte nichts davon, fuer begin/end eine eigene Zeile zu verschwenden. Ich formatiere immer so (bzw. lasse formatieren):

Delphi-Quellcode:

if bla then begin
  blub;
end else begin
  Trallala;
end;

Ich formatier das auch so wie Dummzeuch.

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1464151)

Zitat:

Zitat von dummzeuch (Beitrag 1464142)

Der von Delphi scheiterte bereits an so Sachen wie Variant Records (zumindest beim letzten Mal, als ich es versucht habe, es gibt einen QC-Report von mir dazu). Es gab noch weitere Fehler, aber die sind inzwischen wohl teilweise behoben. Ich benutze ihn aber eigentlich nicht, weil er lange zu fehlerhaft dafür war, deshalb habe ich keinen Überblick, was er kann/nicht kann.

Aktuell (10.3) fällt mir nichts mehr ein was dort wirklich falsch formatiert wird. Variable Records wie in der Unit testfile_VariantExtendedRecord.pas sehen vollkommen in Ordnung aus

Das hier war mein qc-Report:

https://quality.embarcadero.com/browse/RSP-18273

Bezog sich anscheinend noch auf 10.2.

Aber wie ich schon schrieb: Ich benutze den Formatter nur sporadisch und 10.3 quasi gar nicht.

Edit: Der Fehler ist auch in 10.3.3 noch da. Ergebnis:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Test: record a: Integer;
  b: Double;
end;
dt1:
record dt: tdatetime;
s:
string;
end;

begin

end;

[stifflersmom]

Delphi-Quellcode:

if blPausenBrotzuAlt Then Begin

... Niemals

immer so

Delphi-Quellcode:

if blPausenBrotLecker Then
 Begin
  if blLättaAlsAufschnitt Then
   Exit;
 End;

[API]

Zitat:

Zitat von stifflersmom (Beitrag 1464201)

Delphi-Quellcode:

if blPausenBrotzuAlt Then Begin

... Niemals

Genau, das tut einfach weg in den Augen.
Zudem sind die Delphi Sources auch nicht so formatiert.
Da ist es seltsam, wenn man den eigenen Source Code anders formatiert. Aber jedem das seine....

[Uwe Raabe]

Zitat:

Zitat von API (Beitrag 1464203)

Genau, das tut einfach weg in den Augen.

Das sagt wohl jeder zu einer Formatierung, die nicht der von ihm präferierten entspricht. Es ist aber schon ein Stück weit auffällig, wie Entwickler gerade in diesem Punkt eine gewisse Egozentrik aufweisen.

Wichtig ist, daß man sich einigt (oder einer das festlegt) und alle sich daran halten. Von Vorteil ist es, wenn dieses daran halten durch einen Formatierer erzwungen werden kann. Da wohl jeder irgendwie mit den Delphi-Sourcen zu tun haben wird, kann es auch von Vorteil sein, wenn man sich an diesem Standard orientiert.

Am Ende muss aber jeder selbst wissen, wie er seinen Code formatiert - und damit leben, daß andere das vehement kritisieren werden.

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1464206)

Es ist aber schon ein Stück weit auffällig, wie Entwickler gerade in diesem Punkt eine gewisse Egozentrik aufweisen.

Der Zahn wurde bei uns an der Uni gezogen (vielen der Anwesenden zumindest), weil schlicht verschiedene Formatierungen durch objektive Kriterien (Verständniszeit, Auswirkungen auf Merging usw., ...) analysiert wurden.

Seitdem halte ich mich selbst an den offiziellen Styleguide. Vorher habe ich auch z.B. das begin an das Ende der Zeile geschrieben. Aber Regeln wie eben "ein Befehl pro Zeile" wurden dort dann auch noch genauer begründet und mit harten Zahlen untermauert, so dass ich dann für mich persönlich erkannt habe, dass es für mich sinnvoller ist die Vorteile der offiziellen Formatierung mitzunehmen statt viel Zeit in eine eigene Formatierung zu stecken.
Und seit ich das ganze beruflich mache, stellt sich die Frage gar nicht mehr. Da hätte ich für eine eigene Formatierung schlicht keine Zeit mehr.

Aber die Frage nach eigener Formatierung, Dark Mode, Windows Themes, ... ist ja nichts Neues und es wird nie einen gemeinsamen Nenner geben. Von daher sollte es in Teams eben Vorgaben geben und ansonsten ist es gut, dass sich da im Grunde jeder austoben kann wie er möchte. Man sollte sich nur die eigene Flexibilität zumindest so weit bewahren, dass man mit anderen Formatierungen in fremden Quelltexten gut leben kann...

Bei Tools wie dem UnitOptimizer ist daher im Grunde die wichtigste Funktionalität eine möglichst hohe Flexibilität. Das sieht man ja auch an den Einstellungen des internen Formatters oder auch anderer Formatter: Es gibt dort dutzende bis hunderte Einstellungen, damit man die diversen unterschiedlichen Vorstellungen nach Möglichkeit abbilden kann um so optimal zu unterstützen.

Bei uns habe ich entsprechende Vorgaben schriftlich festgehalten wie der Formatter eingestellt werden soll (im Grunde alles auf Standard, nur die Zeilenlänge auf 130 Zeichen) und in den Installationsskripten habe ich diese Einstellungen auch direkt eingebaut. So arbeitet jeder im Team normalerweise mit der gleichen Formatierung.

[stahli]

Suchfunktion weiter ausgebaut: https://youtu.be/1-vMXMATwcA :-)

[API]

Kann man das Tool auch herunterladen (Beta oder so)? (habe jetzt nicht alle 11 Seiten durchgelesen).
Wenn man es ausprobieren kann ist es einfacher, ein Feedback zu geben.

[stahli]

Es fehlen noch mehrere Features und vor allem gibt es auch noch einige ernsthafte Probleme.

Sobald ein stabiler und benutzbarer Stand erreicht ist werde ich hier Tester suchen.
Das wäre jetzt jedoch jetzt noch nicht verantwortbar. Ich hoffe mal, dass ich im Sommer soweit bin.


(Ich hatte zwar schon frühere Testversionen zur Verfügung gestellt, aber jetzt warte ich lieber doch ab, bis das Tool wirklich hilfreich und einsetzbar ist.)

[stifflersmom]

Das Darstellen der Zeilennumern in den Suchbegriffen halte ich für äußerst nützlich und bin froh, dass Gexperts das schon macht.