Delphi 13 Florence wurde veröffentlicht

[dummzeuch]

Zitat von Uwe Raabe:

Genau dafür gibt es ja den Formatter. Würden all gleich die richtige Formatierung schreiben wäre der ja überflüssig.

Naja, es gibt noch weitere Gründe einen Formatter zu benutzen:

• Faulheit (mein liebster Grund, manuelles formatieren nervt)
• Erkennen von irreführenden (manuellen) Formatierungen, z.B. Einrücken eines Blocks nach if..then, ohne dass es darum ein begin..end gibt.

[freimatz]

Zitat von ggscholz:

Es kommen ja immer mal hier Themen vor, wo man sich wünscht, das die immer älter werdenden (durchaus netten) Herrn hier auch mal ernsthaft zu Baustellen in Ihrem Delphi Stellung nehmen. Es würde ihnen auf jeden Fall kein Zacken aus der Krone fallen, eher das Gegenteil: man würde sich jetzt nicht hier unterhalten, ob die 13 gerechtfertigt ist (was ich im übrigen auch so sehe, es ist eine 12.4)

Wenn Du eine konkrete Frage stellen würdest... Ich bin verwirrt.
Ist die Frage die, ob die 13 gerechtfertigt ist? Was meinst Du mit gerechtfertigt? Jeder Softwareherausgeber kann eine Version benennen wie er will, rechtfertigen muss er sich dabei nicht.

[ggscholz]

Zitat von freimatz:

Zitat von ggscholz:

Es kommen ja immer mal hier Themen vor, wo man sich wünscht, das die immer älter werdenden (durchaus netten) Herrn hier auch mal ernsthaft zu Baustellen in Ihrem Delphi Stellung nehmen. Es würde ihnen auf jeden Fall kein Zacken aus der Krone fallen, eher das Gegenteil: man würde sich jetzt nicht hier unterhalten, ob die 13 gerechtfertigt ist (was ich im übrigen auch so sehe, es ist eine 12.4)

Wenn Du eine konkrete Frage stellen würdest... Ich bin verwirrt.
Ist die Frage die, ob die 13 gerechtfertigt ist? Was meinst Du mit gerechtfertigt? Jeder Softwareherausgeber kann eine Version benennen wie er will, rechtfertigen muss er sich dabei nicht.

Sorry, ich wollte nicht verwirren. Ich wollte meinen Beitrag zur Veröffentlichung von D13 schreiben.

Ein konkrete Frage habe ich auch nicht geäußert. Und es ist jedem überlassen, seine Software mit Versionsnummer nach Wahl zu versehen. Da will ich mich nicht einmischen.

Meine (und da bin ich anscheinen nicht allein) Erwartung ist eine andere, wenn man den Namen und die Nummer der Version ändert. So ist das mit Erwartungen: sie werden nicht immer erfüllt.

[jaenicke]

Zitat von dummzeuch:

[*]Faulheit (mein liebster Grund, manuelles formatieren nervt)

Ich denke über das Formatieren gar nicht nach. Ich schreibe den Code automatisch so, dass der Formatter in der Regel keine Anpassungen mehr vornimmt.

Zitat von Der schöne Günther:

Es gibt bis heute noch nicht mal eine (öffentliche) Formale Beschreibung der Delphi-Sprachsyntax [1], oder?

Eine Grammatik gibt es nicht, nein. Aber hier ging es ja um Formatierung und einen Styleguide gibt es in alt und neu:
http://www.sourceformat.com/coding-s...hi-borland.htm
https://docwiki.embarcadero.com/RADS...al_Style_Guide

Nebenbei hat der im letzten Beispiel hier eine Klammer zu viel oder zu wenig:
https://docwiki.embarcadero.com/RADS...te_Space_Usage

Es gibt nur einen Punkt, an dem ich mit dem Styleguide nicht einverstanden bin, weil ich es schlecht lesbar finde:

Zitat:

A continuation line should never start with a binary operator.

Delphi-Quellcode:

if (X = Y) or (Y = X) or
  ((Z = P) and (F = J)) or (A = B) then
begin
  S := J;
end;

Sehr viel besser lesbar finde ich, wenn der Operator am Anfang steht und logische Zusammenhänge eingerückt sind:

Delphi-Quellcode:

if (X = Y) 
  or (Y = X) 
  or ((Z = P) 
    and (F = J))
  or (A = B) then
begin
  S := J;
end;

(Noch besser ist natürlich, wenn man die einzelnen Bedingungen in sprechend bezeichnete Variablen packt. )

Aber wenn es so sein soll, dann sei es so. Ich kann mich anpassen, auch wenn ich es nicht mag. Und deshalb habe ich auch kein Problem mit einem Formatter, der wenige Optionen bietet.

// EDIT:
Ach ja: Wirklich wichtig finde ich ein integriertes Refactoring. Die Formatierung klappt auch ohne LSP-Informationen und auch mit externer Formatierung. Teile einer Datei zu formatieren, wie es angesprochen wurde, sollte allerdings wieder möglich sein, auch wenn ich nicht viel davon halte.

[Uwe Raabe]

Zitat von fisipjm:

Die ganze Gexperts Suite zu installieren nur um einen Formatter zu haben ist leider eine Kanonen auf Spatzen Variante.

Vielleicht kann ich da ja behilflich sein. Ich habe mal ein kleines Delphi-Projekt erstellt, mit dem der Formatter weitestgehend isoliert wird. Das Ganze ist ziemlich einfach und schlicht gehalten. Man muss es selbst compilieren und als Expert in die Registry eintragen. Der ShortCut ist auf Ctrl+D festgelegt und die Konfiguration findet man im Hilfe Menü unter Hilfe-Experten.

Natürlich braucht man dazu die GExperts Sourcen. Das geht z.B. in dem man hier in SourceForge auf Download Snapshot klickt und das Archiv entpackt. In das Root-Verzeichnis kopiert man die beiden Dateien aus dem anhängenden Archiv. Das Projekt dann in der D13 IDE öffnen und für die gewünschten Plattformen compilieren.

Die erzeugten DLLs kopiert man an einen geeigneten Ort und legt in der Registry unter Experts bzw. Experts x64 einen neuen Eintrag namens CodeFormatter und dem vollständigen Pfad als Wert ein.

Die Einstellungen werden in der Datei Formatter.ini im Embarcadero AppData Verzeichnis abgelegt. Ich verwende bewusst nicht den Settings-Mechanismus von GExperts, weil ich den erstmal durchschauen müsste.

Wer mag, kann das Prozedere ja noch etwas automatisieren (z.B. build.cmd, install.reg o.ä.) und die entsprechenden Dateien hier posten.

[dummzeuch]

Zitat von Uwe Raabe:

Natürlich braucht man dazu die GExperts Sourcen.

Wer mag, kann das Prozedere ja noch etwas automatisieren (z.B. build.cmd, install.reg o.ä.) und die entsprechenden Dateien hier posten.

Bevor jetzt jemand auf die Idee kommt, eine vorcompilierte DLL anzubieten und sie evtl. noch mit einem Installer zu versehen:

Die GExperts-Lizenz setzt dem enge Grenzen:

Zitat:

GExperts License Agreement

GExperts is copyright 1996-2025 by Thomas Mueller, Erik Berry and the GExperts development team. This license agreement only covers code written by Erik Berry and the rest of the GExperts development team who have specifically submitted their code for inclusion with GExperts. You should contact the other third-party authors concerning their respective copyrights and conditions.

The rules governing the use of GExperts and the GExperts source code are derived from the official Open Source Definition, available at http://www.opensource.org. The conditions and limitations are as follows:

Usage of GExperts binary distributions is permitted for all developers. You may not use the GExperts source code to develop proprietary or commercial products including plugins or libraries for those products. You may use the GExperts source code in an Open Source project, under the terms listed below.

You may not use the GExperts source code to create and distribute custom versions of GExperts under the "GExperts" name. If you do modify and distribute custom versions of GExperts, the binary distribution must be named differently and clearly marked so users can tell they are not using the official GExperts distribution. A visible and unmodified version of this license must appear in any modified distribution of GExperts.

Custom distributions of GExperts must include all of the custom changes as a patch file that can be applied to the original source code. This restriction is in place to protect the integrity of the original author's source code. No support for modified versions of GExperts will be provided by the original authors or on the GExperts mailing lists.

All works derived from GExperts must be distributed under a license compatible with this license and the official Open Source Definition, which can be obtained from http://www.opensource.org.

Please note that GExperts, Inc. and the other contributing authors hereby state that this package is provided "as is" and without any express or implied warranties, including, but not without limitation, the implied warranties of merchantability and fitness for a particular purpose. In other words, we accept no liability for any damage that may result from using GExperts or programs that use the GExperts source code.

If you have questions about this license, please email Erik Berry.

Das soll jetzt nicht heißen, dass ich grundsätzliche dagegen bin, dass Uwe den GExperts-Code so verwendet.

[Uwe Raabe]

Genau aus dem Grund habe ich ja das Projekt bereitgestellt und keine Binaries. Es muss halt jeder für sich selbst übersetzen.

Am Ende ist aber wohl auch nur Augenwischerei. Das Compilat ist mit über 1 MB viel zu groß für einen simplen Formatter. Es ist halt schon ein gewisser Unterbau von GExperts drin enthalten von dem vieles sicher nicht gebraucht wird. Das leidige Problem mit den Abhängigkeiten.

Das Installieren der originalen GExperts DLL geht vermutlich auch einfacher und schneller. Es ist halt nur ein Angebot und entstanden weil ich selbst wissen wollte ob das überhaupt möglich ist.

[pustekuchen]

Zitat von fisipjm:

damit ich es produktiv in einem mehrköpfigen Entwickelerteam einsetzen kann. ... Leider kann ich nicht jeden Entwickler zwingen, sich daran zu halten. Wenn ich Teile einer unit bearbeite, die ich nicht selbst geschrieben habe, markiere ich den Bereich den ich bearbeite und lasse nur diesen Formatieren. Das geht mit pasfmt nicht weil er nicht in die IDE Integriert ist, sondern von außen die komplette Datei angeht. Damit ist das ein K.O. Kriterium für mich, weil ich meine Kollegen nicht zwingen kann den "neuen" Style zu übernehmen.
Ein issue das diesen Punkt adressieren würde ist schon seit über 1 Jahr offen. https://github.com/integrated-applic...sfmt/issues/58

Dazu kann ich nur empfehlen, dass man sich mit dem Team einmal zusammen setzt und das Ergebnis von pasfmt an einem Projekt/Library vorführt. Wenn es keine bedenken gibt, sollten dann alle Projekte komplett formatiert werden.

Code:

.\pasfmt.exe <project-path>

Innerhalb weniger ms ist das gesamte Projekt formatiert.

Dazu dann auch einen seperaten MR/Commit, damit man nicht formatierung und andere Änderungen durcheinander bringt.

Anschließend ist pasfmt einfach für jeden pflicht und es gibt gar nicht das Problem, das man nur einen Teil formatieren muss Die pasfmt IDE Integration wird dann von jedem installiert und schon ist jeder individuelle Formatierungsstil geschichte.

In unserer Pipeline wird dann auch noch explizit geprüft (mit --check), ob pasfmt eine fehlende Formatierung erkennt. Wenn ja -> BUILD Failed.

Meines erachtens hilft es in diesem fall nur einen einheitliche Entscheidung zu treffen und diese auch radikal durchzusetzen. Die Vorteile eines einheitlichen Formattierten Codes überwiegen immens.

Sollte ein Codeblock mal wirklich nicht formatiert werden, dann gibt es {pasfmt off} / {pasfmt on}