UnitOptimizer

[dummzeuch]

Zitat von stahli:

Der Compiler dürfte zwischen der originalen Standardformatierung von Delphi und der Formatierung durch den UO keinen wesentlichen Unterschied feststellen.
Es sind ja (abgesehen von den weichen Zeilenumbrüchen) nur Zeilen verschoben und Leerzeichen eingefügt bzw. gelöscht.

Abgesehen von einigen Kinderkrankheiten kann ich zumindest keine Probleme feststellen.

Mit Mio Codezeilen habe ich natürlich keine Erfahrungen.

Falls Du mal weinen willst: Ich kann Dir zum Testen die Unit-Tests des GExperts Code Formatters empfehlen. Zu finden im Subversion Repository auf Sourceforge. Die meisten davon habe ich hinbekommen, aber an einigen knabbere ich noch. (Einige schafft der Code Formatter von Delphi auch nicht.)

[stahli]

@dummzeuch

Danke. Ich habe sie mir mal geladen.
3 Abbrüche hatte ich. Die sind jetzt bereinigt.
Ich muss mir die Ergebnisse aber mal noch konkret durchsehen, ob diese "korrekt" sind.
Ist natürlich auch immer die Frage, was man unter korrekt versteht.
Da spielt ja auch immer der persönliche Geschmack hinein - bzw. welche unterschiedlichen Ergebnisse die einzelnen Optionen bringen...

Die testfile_LargeFile.pas braucht 13 Sekunden. 27.000 Zeilen in einer Unit sind ja aber sicherlich auch eher ungewöhnlich. Vielleicht lässt sich das auch noch etwas beschleunigen.
Mein Optimizer geht übrigens nicht nur strikt vorwärts durch die Zeilen und verschiebt die Wörter sondern zerlegt alles und baut das neu zusammen, um die Reihenfolge des Implementationsteils an den Interfaceteil anzugleichen. Das dauert dann halt etwas bei so großen Units.

Das aktuelle Ergebnis ist da aber definitiv auch noch nicht in Ordnung.
Das Problem muss ich noch in Ruhe analysieren.

Ein aktuelles Problem ist mit Sicherheit, dass der Optimizer zwischen echtem Kommentar und Auskommentierungen unterscheidet.
Durch diese Unterscheidungen kann er Kommentare besser im Quelltext einbinden oder z.B. mit Methoden zusammen verschieben.

Delphi-Quellcode:

{
procedure TestXYZ;
begin
end;
}

procedure TestB;
begin
end;

{: 
  Das ist die Prozedur Test.
  Author: StahliSoft
:}
procedure TestA;
begin
end;

Wenn die Prozedur TestA verschoben wird, dann bindet der Optimizer zuvor den darüber befinden echten Kommentar ( {: ... ) an die Methode und verschiebt diesen mit.
Den Block mit TestXYZ versteht er dagegen als Code und bindet diesen nicht an TestB.

Ich kann natürlich eine Option "KeineUmsortierungDesQuelltextes" oder "KommentarImmerAlsEchtenKommentarAnsehen" anbieten.

Aber erst mal muss ich mir die aktuellen Ergebnisse und Probleme mal genauer ansehen...

(Wo scheitern z.B. Du und der Code-Formatter von Delphi? Hast Du direkt mal ein Beispiel zur Hand? (gern auch per Mail))


@Uwe

Ich sehe schon einen Unterschied darin, ein eigenes Projekt zu entwickeln und in anderen Units etwas nachzulesen.
Wenn ich mit einer eigenen Formatierung gut zurecht komme, kann ich ja dennoch anders formatierten Code lesen und verstehen.
Den Hauptaspekt würde ich aber auf das eigene Projekt legen.

Das Wichtigste ist: Formatieren auf Knopfdruck!

Einrücken und Umbrüche von Hand zu schreiben würde ich unbedingt vermeiden wollen.
Daher habe ich immer Ctrl-D benutzt, auch wenn mir das Ergebnis an vielen Stellen nicht wirklich gefallen hat.

Das "hanging begin" habe ich auch noch in der Planung (wird nicht schwierig, habe nur andere dringendere Optionen in Arbeit). Ich habe das auch schon bei einem Tester gesehen und hätte nicht gedacht, dass diese Formatierung verbreitet sein könnte...
Aktuell behält der UO den Code bei wie er gegeben ist. Also "begin" bleibt hinter "then" oder in der neuen Zeile stehen. Als Option will ich anbieten, eine von beiden Varianten "erzwingen" zu können.


Daher mal:


@all

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht oder für wen käme das nie in Frage?

Delphi-Quellcode:

if x then begin
  y := 0;
  z := 0;
end;

[jaenicke]

Zitat von stahli:

Wer nutzt die Formatierung "hanging begin", also, dass begin nicht in einer neuen Zeile steht oder für wen käme das nie in Frage?

Ich halte mich an Regel, dass man nicht mehrere Befehle in einer Zeile hintereinander hängen sollte, damit man nicht etwas davon übersieht und damit es weniger Probleme mit Versionsverwaltungen gibt. Und daher gehört auch das begin in eine eigene Zeile.

Beim Mergen gibt es nämlich ansonsten auch gerne mal "schöne" Ergebnisse, wenn nämlich beim automatischen Mergen das begin hinten in der Zeile entfernt wird, aber das end nicht. Diese Dinge kann man zwar dann korrigieren, aber besser ist es das begin in eine eigene Zeile zu schreiben, damit es beim Mergen auch separat behandelt wird.

Denn anders als der Delphi-Compiler handelt ein Merging-Tool nicht unbedingt semantisch korrekt... da ist es dann in Bezug auf das Ergebnis nicht egal wo das begin steht.

[dummzeuch]

Zitat von stahli:

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

Deshalb habe ich es auch in den Unittests. Der originale DelForEx (auf dem der von GExperts aufbaut) brauchte dafür Ewigkeiten. Das war eine meiner ersten Verbesserungen. Jetzt ist es weniger als eine Sekunde.

Zitat von stahli:

(Wo scheitern z.B. Du und der Code-Formatter von Delphi? Hast Du direkt mal ein Beispiel zur Hand? (gern auch per Mail))

Der von GExperts scheitert vor allem an einigen Generics, siehe die Bug-Reports

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.

Apropos: GExperts erlaubt es Bereiche von der Formatierung auszunehmen:

Delphi-Quellcode:

{(*}
hier; nicht; formatieren;{*)}

Das geht IIRC bei Delphi nicht, d.h. man ist dem Formatter ausgeliefert.

Zitat von stahli:

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;

[jaenicke]

Zitat von dummzeuch:

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, und auch die testfile_LargeFile.pas sieht auf den ersten Blick gut aus und ist in ca. 2 Sekunden formatiert.

[dummzeuch]

Zitat von jaenicke:

Zitat von dummzeuch:

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]

if blPausenBrotzuAlt Then Begin ... Niemals

immer so

Delphi-Quellcode:

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

[API]

Zitat von stifflersmom:

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

[Harry Stahl]

Zitat von dummzeuch:

Zitat von stahli:

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

Zitat von stahli:

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.