Delphi’s Object Pascal Style Guide erneuert

[Uwe Raabe]

War ja auch schon ein wenig in die Jahre gekommen: Delphi’s Object Pascal Style Guide

Blog von Marco Cantú: New Delphi’s Object Pascal Style Guide

[DieDolly]

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

[Uwe Raabe]

Zitat:

The updated version has been curated by Delphi Product manager Marco Cantu, with contributions from the internal R&D team, Delphi MVPs, and the Delphi community at large.

Die Diskussion innerhalb der beteiligten MVPs war teilweise schon sehr unterhaltsam :-D

[ConstantGardener]

<OT> Formatierung ist die eine Sache, wichtiger wäre, das LSP das gleiche Delphi/Object Pascal spricht bzw. versteht. Aber so langsam denke ich das werden wir nicht mehr erleben.</OT>

[himitsu]

Allen Recht kann man es auch nicht machen.
Ich hab einfach meine eigene Variante wann BEGIN-END oder so, und wie eingerückt wird, weil "ich" es einfach so besser lesen kann.
Je nach Situation gibt es auch mal Unterschiede in der Einrückung.

Und dann natürlich alles nochmal anders, bei Fremdcode oder auf Arbeit (jenachdem welche/wessen Unit/Funktion man dort anfasst und wie es da drumrum aussieht).


Aber ja, vor allem für alle ohne "eigenen" Style,
bzw. wenn sie noch garkeinen haben (oder der echt grauenhaft ist)
und zum Reflektieren/Überdenken des eigenen Styles,
ist so eine Vorgabe Ideenvorlage schon nicht schlecht.

[Uwe Raabe]

Zitat:

Zitat von ConstantGardener (Beitrag 1488216)

<OT> Formatierung ist die eine Sache, wichtiger wäre, das LSP das gleiche Delphi/Object Pascal spricht bzw. versteht. Aber so langsam denke ich das werden wir nicht mehr erleben.</OT>

Das gleiche wie was?

[himitsu]

Compiler, ErrorInsight, CodeInsight, HelpInsight, Refactoring, die Änderungen vom FormDesigner oder synchronisierte Codeändeungen aus den Projektoptionen, usw.
Also alles mit der selben Syntax aus'm LSP arbeitet.

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

[Der schöne Günther]

Cool, ich bin mal gespannt ob ich etwas finde über das man sich so fanatisch streiten kann wie Tabs vs. Spaces.


Edit:

Zitat:

Never use tab characters

(Quelle)
👿 AAAAaaaaaa


PS: Wenn ich es beim Überfliegen richtig sehe dann habt ihr euch ja zum Glück auf eine doch sehr brauchbare Formatierungsvorgabe für anonyme Methoden geeinigt. Was man manchmal seht wie manche Leute die in den Code quetschen oder ausrichten, da rollen sich einem die Fußnägel hoch...

[himitsu]

http://docwiki.embarcadero.com/RADSt...te_Space_Usage

Nee nee nee, das geht so. :angle2:

Delphi-Quellcode:

if DoSomething then
  {$IFDEF MSWINDOWS}MessageBox{$ELSE}WriteLn{$ENDIF}('Hello');

Das mit den Anonymen mach ich auch schon so.
Nur manchmal kommt die ProzedurDeklaration mit auf die selbe Zeile (wenn keine/wenige/kurze Parameter und die restliche Zeile davor auch kurz ist), aber das begin-end ist dennoch auf einer eigenen Zeile und immer eingerückt.

[ConstantGardener]

Zitat:

Zitat von Uwe Raabe (Beitrag 1488219)

Zitat:

Zitat von ConstantGardener (Beitrag 1488216)

<OT> Formatierung ist die eine Sache, wichtiger wäre, das LSP das gleiche Delphi/Object Pascal spricht bzw. versteht. Aber so langsam denke ich das werden wir nicht mehr erleben.</OT>

Das gleiche wie was?

Wie Himitsu es schon richtig schrieb! Es nervt mittlerweile wirklich, dass CodeInsight, ErrorInsight, Codevervollständigung usw. zu anderen Ergebnissen kommen wie der Compiler usw. Code ohne Fehler enthält angeblich Fehler, Code mit Fehler ist angeblich fehlerfrei usw. Ich hatte da echte Hoffnung auf LSP gesetzt, und ja ich weiß in der ersten Version kann sowas nicht perfekt sein. Wir haben mittlerweile aber die 3. Version mit LSP und es wird gefühlt immer schlimmer. Und sag mir jetzt bitte nicht ich muss meinen Code anpassen, entkoppeln, zirkuläre Referenzen minimieren etc. pp.

Wenn der Compiler es kompilieren kann, sollte es das Tooling auch können! frei nach Vincent Parret

Um den Bogen zum Thema zu bekommen: Mir wäre ein funktionierender LSP bedeutend wichtiger als ein Style Guide!

cu cg

[jbg]

Was ist denn mit dem "end;" vom "case" los. Das gehört mir persönlich immer auf die Ebene vom "case" und nicht wie im neuen Style Guide, wenn ein "else" Zweig vorhanden ist, eingerückt.
http://docwiki.embarcadero.com/RADSt...phi_Statements

Neuer Style Guide:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
  else
    ...
  end; // huch?

So mache ich das:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
else
  ...
end;

[himitsu]

Ich rücke das ELSE genauso ein, wie oben die Werte, denn die gehören ja zusammen,
aber das letzte END kommt natürlich unters CASE.

BEGIN-END bei den Werten rücke ich aber (meistens) nicht nochmal ein.
BEGIN hinter : und END unter den Wert.
Somit ist Code, egal ob mit oder ohne BEGIN-END oder im ELSE, auch immer auf der gleichen Ebene.

Ein BEGIN hinter ELSE und dazu ein eigenes END ist ja optional, aber das schreib ich dennoch, wenn mehr als eine Zeile ... dann passt das mit der Einrückung auch gleich viel besser.

[Jasocul]

Zitat:

Zitat von himitsu (Beitrag 1488240)

Ich rücke das ELSE genauso ein, wie oben die Werte, denn die gehören ja zusammen,
aber das letzte END kommt natürlich unters CASE.

BEGIN-END bei den Werten rücke ich aber (meistens) nicht nochmal ein.
BEGIN hinter : und END unter den Wert.
Somit ist Code, egal ob mit oder ohne BEGIN-END oder im ELSE, auch immer auf der gleichen Ebene.

Ein BEGIN hinter ELSE und dazu ein eigenes END ist ja optional, aber das schreib ich dennoch, wenn mehr als eine Zeile ... dann passt das mit der Einrückung auch gleich viel besser.

Genau so und nicht anders mache ich das seit über 30 Jahren.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1488228)

http://docwiki.embarcadero.com/RADSt...te_Space_Usage

Ich hab da gerne meine eigenen Regeln, ich nenne das "luftiger Stil", der besseren Lesbarkeit wegen.

Zitat:

Before or after a .(dot) operator

Möglichst ":=" und "=" untereinander, möglichst zusammenhängende Terme ausgerichtet.
Logische Verknüpfungen möglichst separiert, mit vorangestelltem operator.
Möglichst "luftiges" Design durch Spaces in () und [].

Delphi-Quellcode:

  Obj1______________ := TObj1.Create;
  Obj1.___Field1____ := True;
  Obj1.___Field2____ := False;
  //
  Obj1______________ := TObj1.Create;
  ObjNew2.Field3____ := True;
  ObjNew2.Field4____ := False;

  Obj1.___Liste[ 0 ] := 'null';
  Obj1.___Liste[ 1 ] := 'eins';

  if____________( Obj1.___Field1 =_ ObjNew2.Field1 )
    ____and_____( ObjNew2.Field2 <> Obj1.___Field2 ) 
    _// and_____( ObjNew2.Field1 <> Obj1.___Field2 )    //<== So kann man mal schnell Terme ein/ausschalten, und behält doch den Überblick
    ____and not ( Obj1__________ =_ ObjNew2_______ ) then
  begin
  end;

Ja, das ist gewöhnungsbedürftig, aber der Compiler hat sich noch nie beschwert und die Lernkurve ist flach :stupid:

Edit:
Musste es mit ___ verunstalten, wg. der Forensoftware, damit man den Effekt sieht.

[himitsu]

Nee, nach Punkten trenn ich nicht (keine Leerzeichen reingemischt, *1), aber dahinter richte ich bei mehreren Zuweisungen auch die := immer untereinander aus.

1) außer bei langen Ausdrücken ein Zeilenumbruch vor dem Punkt, also Punkt in neuer Zeile, damit man sieht dass es eine Fortsetzung ist (und natürlich eine Stufe eingerückt).

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1488250)

Nee, nach Punkten trenn ich nicht (keine Leerzeichen reingemischt, *1), aber dahinter richte ich bei mehreren Zuweisungen auch die := immer untereinander aus.

Ja so fing das Symptom bei mir auch an :gruebel:

[Jasocul]

Ausrichtung von Zuweisungen mache ich auch am ":=".
Bei mehrzeiligen Bedingungen weiche ich vom Standard ab:

Delphi-Quellcode:

if bla1 and
   bla2 and
   bla3 then
begin
  ...
end

Analog bei ähnlichen Konstrukten.
Da könnte mn noch diskutieren, ob die logische Verknüfung ("and" im Beispiel) in die neue Zeile kommt.

[KodeZwerg]

Zitat:

Zitat von jbg (Beitrag 1488238)

Was ist denn mit dem "end;" vom "case" los. Das gehört mir persönlich immer auf die Ebene vom "case" und nicht wie im neuen Style Guide, wenn ein "else" Zweig vorhanden ist, eingerückt.
http://docwiki.embarcadero.com/RADSt...phi_Statements

Neuer Style Guide:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
  else
    ...
  end; // huch?

So mache ich das:

Delphi-Quellcode:

case ch of
  '0': 
    begin
      ...
    end;
else
  ...
end;

Ich meist so:

Delphi-Quellcode:

case ch of
  '0': begin
         ...
       end;
  else
    ...
end;

[Uwe Raabe]

Eine wichtige Erkenntnis aus den internen Diskussionen um den Style Guide war übrigens: Wähle die Regeln so, dass der interne Formatter es umsetzen kann.

Ich bin mir gar nicht sicher, ob das für den neuen Style Guide überhaupt gilt. :gruebel:

[himitsu]

Zitat:

Zitat von Jasocul (Beitrag 1488256)

Bei mehrzeiligen Bedingungen weiche ich vom Standard ab:

Delphi-Quellcode:

if bla1 and
   bla2 and
   bla3 then
begin
  ...
end

wobei ich hier die and/or/+/... vorne hab,
also wie bei den Punkten, damit man sieht was die neue Zeile macht und nicht erst darüber hinten suchen zu müssen.

Die Ausrichtung mit unterschiedlich langen AND und OR ist zwar bissl "hakelig", aber da kommt dann einfach ein Leerzeichen hinters OR.


Klar, bei dir passen and und then natürlich optisch besser zusammen,
aber auch wenn Andere auch das THEN auf eine neue Zeile unters IF machen, so bleibt es bei mit hinten (nach dem THEN, eventuell mit BEGIN-END, sieht man ja an der Einrückung, dass dort hinten ein THEN stehen muß)

[Frickler]

Zitat:

Zitat von KodeZwerg (Beitrag 1488257)

Ich meist so:

Delphi-Quellcode:

case ch of
  '0': begin
         ...
       end;
  else
    ...
end;

Kommt bei mir immer drauf an, wie lang die Labels sind.

Kurze Labels:

Delphi-Quellcode:

case ch of
  '0': begin
         ...
       end;
  '1': begin
         ...
       end;
  else
    ...
end;

Lange Labels:

Delphi-Quellcode:

case aufzaehlungstyp of
  atZiemlichLangerName:
    begin
      ...
    end;
  atAndererNochVielLaengererName:
    begin
      ...
    end;
  else
    ...
end;

[KodeZwerg]

@Frickler: Ja, das geht so auch in Ordnung für mich. Mir war es halt wichtig zu zeigen wo mein "else" steht.

[perpeto1234]

Es wäre dann ja mal schön, wenn der Code-Formatter (Strg+D) nicht bei Inline-Variablen Zeilenumbrüche ergänzen würde. Das nervt mich so unglaublich. Früher war es eine Wohltat "Strg+D" zu hämmern.. aber das habe ich mir nur leider deshalb abgewöhnt.

Aus:

Delphi-Quellcode:

var Zahl := 1;

Wird:

Delphi-Quellcode:

var
  Zahl := 1;

Toll!

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1488259)

Eine wichtige Erkenntnis aus den internen Diskussionen um den Style Guide war übrigens: Wähle die Regeln so, dass der interne Formatter es umsetzen kann.

Ich bin mir gar nicht sicher, ob das für den neuen Style Guide überhaupt gilt. :gruebel:

Wenn man jetzt bloß jemanden kennen würde, der den Sourcecode für den Formatter hat und den anpassen könnte :gruebel:

[himitsu]

Situationsbedingte Ausnahmen/Abweichungen sind für so Automatiken aber auch nicht immer leicht.

Je nach umgebendem Code passe ich meine Formatierung in Nuancen teilweise etwas an (Leerzeichen, Zeilenumbruch und Einrückung)

Beim VAR in Prozedurheadern und global ebenso mit Zeilenumbruch,
aber als Inline natürlich auch einzeilig.


z.B. bei "massenhaften" Parameterübersetzungen mach ich den Code direkt hinters THEN und THEN untereinander ausgerichtet,
aber wenn nur 1 oder 2 solcher Zeilen, oder wenn das im IF länger, dann auch mit Zeilenumbruch nach dem THEN.

Delphi-Quellcode:

if A then Include(C, D);  // bzw. C := C + [D]; oder sowas
if B then Include(E, F);
...

[stahli]

Also ich will auf jeden Fall eine Lösung, die komplett auf Knopfdruck funktioniert.
Notfalls würde ich auch mit ein paar Kleinigkeiten leben, die mir nicht ganz gefallen. Einiges kann man ja auch optional einstellbar machen.
Auf keinen Fall würde ich irgendwas händisch zurecht schieben.

Meinen Formatierer überarbeite ich gerade nochmal (läuft ganz gut).
Ich will zwar genau zu dem Ergebnis kommen, das ich schon erreicht hatte aber mein jetziger Weg kommt mit weniger Spezialbehandlungen aus als der letzte und ermöglicht auch eine bessere Codevervollständigung und Sortierung.

Eine Schwierigkeit ist z.B. dass ich auskommentierten Code als echten Code interpretiere und formatiere.
Das Ausrichten von bestimmten Codestellen (z.B. ":=") untereinander will ich unbedingt haben. Das finde ich sehr übersichtlich und hilfreich.

[TiGü]

Zitat:

Zitat von Rollo62 (Beitrag 1488246)

Möglichst ":=" und "=" untereinander, möglichst zusammenhängende Terme ausgerichtet.
Logische Verknüpfungen möglichst separiert, mit vorangestelltem operator.
Möglichst "luftiges" Design durch Spaces in () und [].

Delphi-Quellcode:

  Obj1______________ := TObj1.Create;
  Obj1.___Field1____ := True;
  Obj1.___Field2____ := False;
  //
  Obj1______________ := TObj1.Create;
  ObjNew2.Field3____ := True;
  ObjNew2.Field4____ := False;

  Obj1.___Liste[ 0 ] := 'null';
  Obj1.___Liste[ 1 ] := 'eins';

  if____________( Obj1.___Field1 =_ ObjNew2.Field1 )
    ____and_____( ObjNew2.Field2 <> Obj1.___Field2 ) 
    _// and_____( ObjNew2.Field1 <> Obj1.___Field2 )    //<== So kann man mal schnell Terme ein/ausschalten, und behält doch den Überblick
    ____and not ( Obj1__________ =_ ObjNew2_______ ) then
  begin
  end;

Ja, das ist gewöhnungsbedürftig, aber der Compiler hat sich noch nie beschwert und die Lernkurve ist flach :stupid:

Edit:
Musste es mit ___ verunstalten, wg. der Forensoftware, damit man den Effekt sieht.

Puh, dass ist aber schon visueller Horror sondergleichen. :shock:
Das Auge muss doch so unnötig lange Wege zurücklegen.
Na ja, jeder Jeck ist anders.

Ich habe Programmierer und Softwareentwickler noch nie verstanden, die von oben nach unten etwas ausrichten.
Das ist keine Tabellenkalkulation mit Spalten.
Es sind zeilenbasierte An- und Zuweisungen.
Zeile fünf hat (visuell) nichts mit Zeile 24 zu tun.

Delphi-Quellcode:

  ObjNew2.Field3____ := True;
  ObjNew2.Field4____ := False;

Allein hier bekommt man doch voll die Krise, wenn Field4 umbenannt/refaktorisiert wird nach bspw. LongField4Name.
Wird dann überall angefangen händisch (!) die Leerzeichen anzupassen?
Wer bezahlt das?

[DieDolly]

Die meiner Meinung nach einfachste und beste Lösung ist, sich direkt die Schreibweise anzugewöhnen die von STRG+D vorgegeben wird.
Das mit den Leerzeichen, das ist der absolute Horror, schlimmer gehts nicht.

[stahli]

Mein Formatierer macht das Blockweise (siehe Screenshot).

Optional könnte man z.B. noch regeln, dass Sprünge über eine bestimmte Anzahl (sehr geringe Einrückung zu sehr weiten Einrückungen) nicht toleriert werden:

Delphi-Quellcode:

I__: Integer;
IYY: Integer;
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ: Integer;
IYYZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ______: Integer;

Aktuell würden die ersten zwei Zeilen mit nach rechts ausgerichtet, was man aber durch eine Leerzeile verhindern könnte. Alternativ wäre wie gesagt auch eine Option möglich, die solche großen Sprünge verhindert.


Eine Ausrichtung untereinander von Hand würde ich auf keinen Fall machen aber eine solche Ausrichtung auf Knopfdruck finde ich nützlich.

[Rollo62]

Zitat:

Zitat von TiGü (Beitrag 1488292)

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 :stupid:

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:

Zitat von DieDolly (Beitrag 1488208)

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) :stupid:

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:

Zitat von TiGü (Beitrag 1488292)

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:

Zitat von himitsu (Beitrag 1488225)

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:

Zitat von TurboMagic (Beitrag 1488371)

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.