Source Code Formater

[bernhard_LA]

was ist denn aktuell (2021) der bester code Formater für Delphi ?

1. ich hätte gerne einheitliche Schreibweise für alle var's , Befehle etc. , also immer so was wie FMeineVar : String; . das F bei Lokalen Vars ist zwingend
2. typen müssen immer als TMyObject benannt werden
3. .....
4. das ganze Formatierungs Thema kann via XML konfiguiert werden

Hab so was bei IntelliJ & Java , wäre auch cool wenn der Delphi Code so ordentlich dann wäre.

[jaenicke]

Der beste ist finde ich der in Delphi integrierte mit neu eingestellter Breite (z.B. 130 Zeichen, was ich auch im Editor selbst einstelle). Der funktioniert meistens gut und hält sich ohne weitere Einstellungen an die Standardformatierung.

[Uwe Raabe]

Ein Teil deiner Forderungen hat aber nichts mit der Formatierung zu tun, sondern mit Namenskonventionen. Das wird ein reiner Formatter nicht leisten können.

[Mavarik]

Der Formatter der von Delphi mitgeliefert wird, wird von EMBT "gepflegt" und sollte eigentlich immer auf dem aktuellen Stand sein...
Ich einer perfekten Welt.

Mir geht es aber um mehr bei der Sourcecode-Formatierung.

Ich habe schon vor langer Zeit "rumgefragt", wer mir bei der Programmierung des ultimativen Formatters helfen möchte...
Die, die sich gemeldet haben, haben bisher keine einzige Zeile dazu beigetragen.

Da ich meinen Focus momentan auf #DMVVM gelegt habe, komme ich leider selber auch nicht dazu...
Ohne Erklärungen wird man den Source nicht verstehen, daher ist das Repo nicht public.

Ich will Ende des Jahres nochmal einen Blog-post dazu machen und den Fortschritt zeigen.

Zitat von bernhard_LA:

was ist denn aktuell (2021) der bester code Formater für Delphi ?

Vielleicht kann ich die Frage dann 2022 beantworten.

[bernhard_LA]

vielleicht wäre so was wie genormte Coding Styles eine Lösung.

In Java sind doch getter und setter nicht an genormte Namen gebunden, d.h.
durch beliebig unglückliche Funktionsnamen wird dann der Code auch schwer verständlich.
In Delphi gibt dafür die Properties , aber das set.... und get.... ist halt nicht zwingend, dann kann der Code halt auch wieder "Übel" aussehen

Ein Code Review Tool wäre hier perfekt.

[stahli]

Ich arbeite immer noch an meinem Optimizer.

Der wird auch Codevervollständigung und -Änderung vereinfachen - insbesondere was Interfaces und deren Klassenimplementation betrifft.

Hier mal ein kleines Beispiel: https://www.delphipraxis.net/1402961-post3.html

Aus "prop Firstname: String;" in einer Klassendeklaration wird auf Knopfdruck ein komplettes Property mit Getter (_get_Firstname), Setter (_set_Firstname) und privatem Feld (fFirstname).
Die Präfixe und die Codebausteine lassen sich variabel definieren.

Wird das Property in der Form nachträglich in einem Interface aufgenommen, wird die Vervollständigung in allen Klassen durchgeführt, die das Interface verwenden (auch später in anderen Projekten, die das Interface nutzen).

Dazu gibt es gewisse Vorgaben, die man schon in dem Interface einrichten kann. So kann man z.B. schon im Interface festlegen, dass die Klassenmethoden virtuell sein sollen oder der Parameter im Setter als "const". Die Einstellungen werden dann bei der Klassenvervollständigung gleich berücksichtigt (wenn die Methoden neu angelegt werden).

Die Voreinstellungen kommen i.d.R. nur bei Neuerzeugungen von Eigenschaften, Methoden und Feldern zum Tragen. Man kann aber auch Änderungen nachträglich erzwingen.
Hat man Methoden in Klassen z.B. nicht virtuell angelegt, kann man dies durch einen Schalter in der Interface- oder Klassenstruktur korrigieren.
Das könnte dann so aussehen: "prop Firstname: String; !vi"
So würden alle Getter und Setter der Property in allen verwendenden Klassen in "virtuell" geändert werden.

Auch Umbenennungen kann man erzwingen: "prop Firstname: String; !rn First_Name" !rt String[100]
Damit würde der Propertyname und Typ entsprechend durchgehend umbenannt (allerdings nur bezüglich der Getter und Setter und des privaten Feldes "fFirst_Name" (incl. im Codeblock der Getter und Setter)).
Ob man mal irgendwann ein echtes Refactoring innerhalb der IDE anstoßen kann, kann ich derzeit nicht einschätzen. Da muss man ggf. mal noch den besten Weg finden.)

Wenn "First_Name" im aktuellen Projekt nochmal umbenannt wird in "FirstName" und dieses Interface auch in einem anderen ProjektOld verwendet wird, in dem der Stand noch "Firstnamwe" lautete, wird der Optimizer "Firstname" in "FirstName" ändern und den Zwischenschritt überspringen.


Ob das jetzt Deinem Wunsch nahe kommt, kann ich nicht wirklich einschätzen.

[Mavarik]

Zitat von bernhard_LA:

vielleicht wäre so was wie genormte Coding Styles eine Lösung.

In Java sind doch getter und setter nicht an genormte Namen gebunden, d.h.
durch beliebig unglückliche Funktionsnamen wird dann der Code auch schwer verständlich.
In Delphi gibt dafür die Properties , aber das set.... und get.... ist halt nicht zwingend, dann kann der Code halt auch wieder "Übel" aussehen

Ein Code Review Tool wäre hier perfekt.

FixInside macht genau das und wird Dir auch eine Warnung aus, wenn der Getter oder Setter nicht dem Namepattern entspricht.

Property Foo : Integer read GetMyFoo; // Warning.

[Mavarik]

Zitat von stahli:

Hier mal ein kleines Beispiel: https://www.delphipraxis.net/1402961-post3.html

Aus "prop Firstname: String;" in einer Klassendeklaration wird auf Knopfdruck ein komplettes Property mit Getter (_get_Firstname), Setter (_set_Firstname) und privatem Feld (fFirstname).
Die Präfixe und die Codebausteine lassen sich variabel definieren.

Ich habe ja sicherlich auch meine Eigenheiten wie ich etwas formatiere, aber Getter mit _ und dann nochmal _ for dem Name, ist ja voll gruselig.

Da wo ich vom aktuellen Style Guide abweiche hat es wirklich gute Gründe, aber in den Grundlegenden Dingen - (bis auch Kleinigkeiten) - kann ich mich an den Style Guide halten.!

[jaenicke]

Zitat von Mavarik:

Ich habe ja sicherlich auch meine Eigenheiten wie ich etwas formatiere, aber Getter mit _ und dann nochmal _ for dem Name, ist ja voll gruselig.

Unterstriche per se sind ja laut Styleguide nur bei Importen aus anderen Sprachen erlaubt (Windows Messages, ...).

Aufgrund der vergangenen Diskussionen im Forum glaube ich, dass er durchaus weiß, dass er das anders macht als 99% der Delphi-Entwickler, aber jedem das Seine. Solange man Quelltexte nicht im Team bearbeitet oder veröffentlicht, ist das ja ziemlich egal.

Ich möchte solche Quelltexte nur nicht lesen müssen. Deshalb kaufe ich auch grundsätzlich keine Komponenten, bei denen die Beispiele schon deutlich anders als im Styleguide beschrieben aussehen.
Meistens gibt es ja Alternativen.

[stahli]

Zitat von Mavarik:

Ich habe ja sicherlich auch meine Eigenheiten wie ich etwas formatiere, aber Getter mit _ und dann nochmal _ for dem Name, ist ja voll gruselig.

So sieht man immer sofort, dass man einen Getter oder Setter vor sich hat, der normalerweise nicht aufzurufen ist.
Aber wie gesagt, das ist ja nicht zwingend.