Delphi’s Object Pascal Style Guide erneuert

[Rollo62]

Zitat von TiGü:

Das Auge muss doch so unnötig lange Wege zurücklegen.

Das Gehirn "sieht" zusammenhängende Muster aber sofort und viel schneller als den Sinn in einem Zeichenhaufen zu finden,
da wandert nicht viel über den Bildschirm.
Darum geht es.
Ausserdem sollen die Augen ja wandern, und nicht nur auf einen Punkt starren, darüber mache ich mir weniger Sorgen

Muss man nicht so machen, aber probier es halt einfach mal aus, nach einiger Zeit merkst Du die Vorteile.

Ich benutze mittlerweile auch alle Indents 4 statt 2 (das kommt ursprünglich aus Java, glaube ich).
Auch dass mach den Stil "luftiger", und die Umbrüche sind für das Gehirn viel schneller und leichter erfassbar.

[dummzeuch]

Zitat von DieDolly:

Diese "Empfehlung" sollte Pflicht werden, ohne die der Compiler gar nicht erst arbeitet. Dann gäbe es weniger Gruselcode von irgendwelchen Hausaufgaben.

Willkommen bei COBOL (oder Python), wo die Formatierung ein wichtiger Teil der Syntax ist.

Ich für mein Teil bin froh, dass ich die Wahl habe und bin definitiv mit einigen Vorgaben des Styleguides nicht einverstanden. (Den neuen habe ich mir aber noch nicht angesehen, vielleicht hat sich ja was verbessert.)

[himitsu]

Formatierung als Teil der Syntax empfinde ich aber auch bissl "krank".
Wikipedia: Whitespace (Programmiersprache)

Hab auch bissl Python lernen müssen, weil das als ScriptSprache in unserem ReportingSystem mit drin ist.
Und wir hatten zuletzt mit Python4Delphi versucht es direkt einzubinden (noch nicht ganz fertig validiert), um den Aufruf der EXE zu entfernen und die Verbindung zu verbessern.

[Benmik]

Zitat von TiGü:

Das Auge muss doch so unnötig lange Wege zurücklegen.
Das ist keine Tabellenkalkulation mit Spalten.
Zeile fünf hat (visuell) nichts mit Zeile 24 zu tun.

Und warum gibt es dann überhaupt Darstellungen in Tabellenform? Dort haben die Zeilen oft auch nichts miteinander zu tun. Auge und Kopf sind bei einer visuell gegliederten Anordnung viel schneller.

Embarcadero weiß schon sehr genau, warum es Style Guides und nicht dollymäßig Style Commandments veröffentlicht. Obwohl theoretisch völlig unbedeutend, da funktionell ohne Wirkung, erhitzen sich an der Formatierung regelmäßig die Gemüter. Die Programmiererzunft besteht halt tendenziell aus Leuten, die nicht nur eine ausgeprägte Meinung haben, sondern auch feste Überzeugungen hinsichtlich der Wertigkeit und der wünschenswerten allgemeinen Verbindlichkeit ihrer persönlichen Meinungen. Ich als Hobbyprogrammierer würde mich von Delphi abwenden, wenn die Style Guides technisch verbindlich gemacht würden. (Würde Emba wohl verschmerzen.) Ich bin angenehm überrascht, dass einige meiner Vorlieben auch von Profis geteilt werden. Und um TiGüs Frage zu beantworten: Ich habe mir für die Ausrichtung eigens ein kleines Programm geschrieben, das geht also ratzifatzi.

Ich würde an Embas Stelle den Formatierer stark aufwerten und in ein eigenes, ausgewachsenes Programm stecken, das extrem benutzerfreundlich wäre. Ich habe den Verdacht, dass im Programmiergeschäft 40% der Arbeitszeit damit verbracht werden, fremden Code unter einer Flut von abwertenden Bemerkungen umzuformatieren. (Dieser Verdacht ist durch die Lektüre dieses Forums entstanden.) All die Zeit und das ständige Sich-Ereifern könnte man sich sparen: Jeder hat seine persönliche Vorlage parat, einmal STRG+D und der Code ist genau nach persönlichem Gusto. Gibt ja auch die Bibel in ganz verschiedenen Ausführungen, und da wird ja auch jeder selig.

[Stevie]

Wenn die einzige Sorge im Code ist, ob da nun das end um 2 zu viel oder zu wenig eingerückt oder das begin am Ende der vorherigen Zeile steht oder in einer neuen, dann wäre das ja schon nahe an der Perfektion.

Fakt ist, dass der Code, der in Delphi mitgeliefert wird, durchaus sehr gut lesbar ist. Das hat aber in den letzten Jahren leider durch Nichtbeachtung des vorhandenen Guides abgenommen, was auch durch den Zukauf von Fremdcode (ich schaue euch an, FMX und FireDAC) und externe Entwickler für bestimmte Projekte entstand. Aber daran ist auch nicht nur die Formatierung schuld sondern oft auch die Gesamtarchitektur und verschwurbeltes Design und das ist viel wichtiger als ob da nun 2 oder 4 eingerückt wird, wenn das wenigstens konsistent ist.

Das heißt, auch wenn öffentlich zur Verfügung gestellt, ist der Guide mehr für interne Zwecke und solche, die für Embarcadero Code erstellen.

[stahli]

Natürlich gibt es wichtigere Punkte bei der Programmierung als die Codeformatierung.

Aber wenn man ohne Aufwand eine "übersichtliche Formatierung" einstellen kann, dann sollte man das m.E. auch tun.

Im Team muss man sich natürlich einigen, was "übersichtlich" ist bzw. sich getroffenen Regelungen unterordnen.

[TurboMagic]

Zitat von himitsu:

So Copyrightzeugs/Unitbeschreibungen mach ich inzwischen ins PasDoc/XMLDoc, anstatt in einen komischen Kommentar.
Theoretisch könnte das dann im HelpInsight/CodeVervollständigung zum Unitnamen angezeigt werden (wenn es funktionieren würde) oder bei der Generierung einer Dokumentation oder Hilfe genutzt werden.

Kannst ja mal meinen QP Feature Request betreffend XMLDOC für Units raussuchen und dafür stimmen
Dann könnte man einehn <summary> Kommentar über die Unit Deklaration selber schreiben und irgendwo im Uses das als XMLDOC Tooltip angezeigt bekommen.

Grüße
TurboMagic

[pustekuchen]

Gibt es eine Erweiterung wie z. B. clang-format, die diesen Styleguide auch - im möglichen rahmen - anwendet?

[himitsu]

Zitat von TurboMagic:

Kannst ja mal meinen QP Feature Request betreffend XMLDOC für Units raussuchen und dafür stimmen
Dann könnte man einehn <summary> Kommentar über die Unit Deklaration selber schreiben und irgendwo im Uses das als XMLDOC Tooltip angezeigt bekommen.

Muß ich mal nachsehn, ob es auch angezeigt wird.

Was mir vor Kurzem aufgefallen war, wenn man den Oberen in eine Region packt, dann lässt sich auch die Region nicht folden, aber der eine ///-Kommentar, da ganz oben, kann das inzwischen, aber nur innerhalb der Region, nicht einzeln und die Region selber nicht.
Nur mache ich keine Regionen mehr, wobei ...

Ohne ein gekauftes DocumentationInsight (die MiniEmbaVersion wird ja leider nicht mehr ausgeliefert) macht es keinen Spaß alles doppelt zu schreiben,
denn einen bisher unbemerkten Vorteil hatte die Region doch.
* ursprünglich war sie nur, weil /// nicht gefoldet wurde
* ist jetzt aber für eine Kurzvorschau immernoch nützlich ... nja, noch ... hoffe ich bald
https://quality.embarcadero.com/browse/RSP-39651

[arnold mueller]

Warum baut Emba nicht endlich einen gut funktionierenden Code Formatierer? Die Jetbrains IDEs, z.B. für go, formatieren den Code beim Tippen automatisch. Sieht immer gleich und top aus, sehr bequem und hilfreich.