UnitOptimizer

[jaenicke]

Zitat von stahli:

Wenn das Suchproblem nicht bestehen würde (bzw. gelöst wäre), würdest Du dann eine solche Formatierung sinnvoll finden?

Ich persönlich finde es unübersichtlicher, aber das ist eben sehr subjektiv.

Zitat von stahli:

Ich hatte das so verstanden (und kann auch nichts anderes heraus lesen), dass Ihr eine Lösung habt, um ganz normal zu suchen (trotz Einrückungen und Dank einer Konfiguration).

Nein, die Lösung war die Standard-Formatierung zu verwenden und eben alles nach und nach dahingehend zu formatieren.

Der Quelltext ist so auch für mich deutlich besser lesbar, weil es einfach immer genauso formatiert ist wie die meisten Codesnippets im Internet und auch die RTL- und VCL-Quelltexte selbst. Exotische Formatierungen sind ja zum Glück deutlich in der Minderheit.

Aber letztlich jage ich im Zweifelsfall zuerst den Formatter von Delphi drüber, wenn Quelltext anders formatiert ist. Von daher stört mich das wenig, ich muss es ja nicht so lesen.

Ein weiterer Vorteil ist, dass man nicht Änderungen im Repository sieht, weil jemand anders formatiert, sondern nur die echten Änderungen. Und die Differenzansicht funktioniert dann auch viel besser, sprich ist übersichtlicher, wenn nicht noch Leerzeichen mehr oder weniger dazwischen hängen.
Ja, solche Änderungen kann man ausblenden, aber das ändert nichts daran, dass technisch unnötige Änderungen im Repository landen.

Bei uns wird jede einzelne Änderung vor dem Einchecken noch einmal geprüft um nicht Debugcode oder unbeabsichtigte Änderungen einzuchecken. Da sind verschiedene Formatierungen nur hinderlich. Und dazu kommt, dass das Mergen weniger Konflikte verursacht, wenn alle gleich formatieren.

Das erreicht man aber natürlich auch, wenn alle die gleiche eigene Formatierung verwenden (z.B. mit deinem Tool). Ich kenne allerdings kein Team, bei dem alle eine solche verwenden, das sind meistens eher nur einzelne Entwickler.

[stahli]

Ok, kann man natürlich so sehen.

Ich finde den Code mit "Tabulatoren" übersichtlicher und attraktiver. Ist natürlich Geschmacksache und und im Optimizer optional auch abwählbar.

Wichtig ist natürlich, dass die gewünschte Formatierung IMMER AUF KNOPFDRUCK erreichbar ist.
Von händischen Formatierungen halte ich nichts. Bisher habe ich immer die die Standardformatierung genutzt, auch wenn sie mir nicht ganz gefallen hat.



Mal zur Suche:

Eine generelle Änderung der Suchfunktion würde auch Suchen über Umbrüche ermöglichen.
Wenn man z.B. "Vorname, Nachname, Alter" sucht, weil man die irgendwo als Parameter verwendet hat, dann wäre doch eigentlich schön, wenn die IDE eine Codezeile auch findet, wenn vor "Alter" ein Zeilenumbruch eingefügt ist weil die maximale Zeilenlänge sonst überschritten wird.

Noch cooler wäre wenn der Suchbegriff auch so etwas wie:
procedure SetPerson(const Vorname, Nachname: String; const Alter: Integer);
oder
procedure SetPerson(const aVorname, aNachname: String; const aAlter: Integer);
findet.

Ich glaube, ich habe gerade Blut geleckt....

[HeZa]

Für solche Suchen verwende ich DocFetcher.

Dafür exportiere ich täglich alle Source-Repositories und alle Datenbankstrukturen, Trigger, Stored Procedures (IBExpert sei Dank), lass noch ein Tool darüber laufen, dass mir die SQLs aus allen DFM- und FastReport-Dateien extrahiert (um diese komischen Sonderzeichen und Umbrüche loszuwerden).

Vorteile:
* Die Suche darüber ist dann sehr schnell, die Antwort dauert immer nur 1-2 Sekunden.
* Man kann zwei Wörter suchen die bis zu x Wörtern auseinander liegen.

Nachteile:
* Ist eine Wortsuche (* wird allerdings unterstützt), Sonderzeichen wie , := ; " werden nicht gefunden
* Es ist immer der Stand vom Morgen des aktuellen Tages

Vermissen möchte ich das trotzdem nicht mehr.

Ciao HeZa

[stahli]

Ich habe mal eine kleine Testsuche gebastelt... https://youtu.be/LzHs3a2NSZc

Das ist noch recht provisorisch und unansehnlich aber die Funktionalität finde ich schon mal cool.

Was haltet Ihr davon?

Hat jemand Lust, daran mit zu arbeiten?
Ich kann mir vorstellen, dass das sehr nützlich werden kann.


(Jetzt muss ich mal noch einen kleinen Nachtspaziergang machen, um die Kopfschmerzen raus zu laufen und ein wenig runter zu kommen. Kennt Ihr sicher auch nach Doppelschicht am Rechner... )

[jaenicke]

Eine nützliche Codesuche zu bauen ist gar nicht so einfach, da viele Optionen berücksichtigt werden sollten. Zum Beispiel in welchem Unitabschnitt man suchen möchte und ob in Code, Strings oder Kommentaren oder auch ob auch in Formulardateien gesucht werden soll.
Wie ich auf diese Liste komme? Dies ist in den GExperts in der Grep-Suche umgesetzt.

Ich selbst finde Regular Expressions flexibler als eine solche manuelle spezielle Suche.

Wenn du eine solche Suche implementieren möchtest, würde ich es aber im Code der GExperts tun und das Ergebnis an Thomas schicken. Wenn das gut funktioniert, nehme ich an, dass er es dann in seine Releases integrieren würde.
Das hätte den Vorteil, dass die IDE-Integration und die Ergebnisdarstellung schon sehr gut vorhanden sind.

[Uwe Raabe]

Zitat von jaenicke:

Nein, die Lösung war die Standard-Formatierung zu verwenden und eben alles nach und nach dahingehend zu formatieren.

Das haben wir vor ein paar Jahren bei einer 2 Mio. Zeilen großen Codebasis mal über die Kommandozeile gemacht. Seitdem ist das alles viel entspannter und einfacher geworden. Wenn über Jahre viele Entwickler mit unterschiedlichen Formatierungspräferenzen am Code arbeiten, tut ein solcher Hausputz manchmal Wunder.

[stahli]

@jaenicke

Das frei schwebende positionierbare Suchformular war zunächst natürlich eine Testlösung und geplant, das später einzubetten.

Allerdings finde ich das jetzt so DEUTLICH komfortabler. Das Suchformular muss ja nicht ständig offen sein. Allerdings sollte es leicht erreichbar sein und auch genügend Platz bieten.

Daher ist es eigentlich sinnvoller, es nicht in die IDE einzubetten. Möglich wäre das sicherlich, aber letztlich m.E. nur nachteilig.

Schöner machen kann man es ja noch (ich wüsste nur nicht wie genau).


@Uwe

Eine einheitliche Formatierung ist natürlich sinnvoll und es muss komplett auf Knopfdruck erledigt werden. Die Frage ist nur, was mal als "Standard" ansieht.
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.

[Uwe Raabe]

Zitat von stahli:

Eine einheitliche Formatierung ist natürlich sinnvoll. Die Frage ist nur, was mal als "Standard" ansieht.

Das ist - wie so oft - sicher Geschmackssache. Nur kommt man in einem Team nicht sehr weit, wenn jeder seinen eigenen Geschmack favorisiert. Daher legt man einen Style-Guide fest, der von dem verwendeten Formatierer (in unserem Fall dem Delphi eigenen) unterstützt wird. Wenn sich dann dieser Style-Guide noch weitestgehend an dem von Delphi orientiert, hat man auch keinen Bruch zwischen eigenem Code und den Delphi-Units, was dem schnellen Lesen und Erfassen sehr zugute kommt. Wenn ich mir überlege, wie viel Zeit ich mit dem Lesen von Code verbringe, summiert sich jede eingesparte Zehntel-Sekunde zu einer erklecklichen Zeitspanne auf. Ich wundere mich immer wieder über jeden, der diesen Vorteil zugunsten einer Vorliebe für eine eigene Formatierung verspielt.

Wenn man, wie ich, bei verschiedenen Kunden mit unterschiedlichen Style-Guides arbeiten muss, bleibt es natürlich nicht aus, daß man immer mal wieder was anders macht als vorgegeben. So verwende ich aus alter Gewohnheit immer mal wieder (eigentlich recht oft) das Hanging Begin (Zeilenumbrüche vor Begin in Steueranweisungen = Nein). Das lässt sich mit einem beherzten Ctrl-D aber recht schnell bereinigen.

Idealerweise wird vor jedem Check-In automatisch eine entsprechende Formatierung durchgeführt. Das sorgt dann auch für saubere Diffs in den ChangeSets.

[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;