AW: Source Code Formater
was ist denn aktuell (2021) der bester code Formater für Delphi ?
Hab so was bei IntelliJ & Java , wäre auch cool wenn der Delphi Code so ordentlich dann wäre. |
AW: Source Code Formater
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.
|
AW: Source Code Formater
Ein Teil deiner Forderungen hat aber nichts mit der Formatierung zu tun, sondern mit Namenskonventionen. Das wird ein reiner Formatter nicht leisten können.
|
AW: Source Code Formater
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:
|
AW: Source Code Formater
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 :-D, 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. |
AW: Source Code Formater
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. |
AW: Source Code Formater
Zitat:
Delphi-Quellcode:
Property Foo : Integer read GetMyFoo; // Warning.
|
AW: Source Code Formater
Zitat:
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.! |
AW: Source Code Formater
Zitat:
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. |
AW: Source Code Formater
Zitat:
Aber wie gesagt, das ist ja nicht zwingend. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:08 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz