Die "richtige" Sourcecode Formatierung?

[bra]

Zitat von Mavarik:

oder doch lieber so:

Delphi-Quellcode:

type
  TFoo = class
    private
      Procedure Bla;
      Function. Blub : Integer;
      Procedure SetWert( AValue : Integer )
      Function. GetWert : Integer
      Procedure SetText( Const AValue : String )
      Function. GetText : String;
    public
      Property Wert............ : Integer read GetWert write SetWert;
      Property TestmessageValue : String. read GetText write SetText;
   end

Diese Formatierungen mit Einrückungen sind zwar ganz nett zu lesen, aber immer dann wenn man neue Funktionen oder Properties hinzufügt, die länger sind als das schon vorhandene, fängt man an, alles umzuformatieren und das ist einfach zeitaufreibend und nutzlos. Zumal einem die IDE bei sowas überhaupt nicht unterstützt.

Ich bin der Meinung, es gibt keine "richtige" Formatierung, auch weil jeder ein wenig anders tickt und den Quellcode anders erfasst. Ein Kollege macht im Quellcode z.B. keinerlei Leerzeichen und ich finde das immer grauenvoll zu lesen, er kommt damit prima klar.

[Sherlock]

Die IDE unterstützt bei so manchem. Aber das Ausrichten der Methodennamen hat sie halt noch nicht drauf.
Manchmal ist es zu viel des Guten, da wird so weit auseinandergezogen, daß man (ich ) sich in der Zeile vertun kann.

Zum Thema "richtige" Formatierung: Freilich bleibt es Einzelkämpfern überlassen, ihren Code nach Gutdünken zu formatieren. Sie können ihn auch mit rosa Blümchen tapezieren. Aber es gibt tatsächlich Formatierungsrichtlinen von Borland...Codegear...Embarcadero (in der Tat haben die sich seit mindestens 8 Jahren nicht verändert, Generics fehlen komplett und allgemeines Entstauben täte gut). Ein Team, in dem es bekanntlich keine Einzelkämpfer gibt, tut gut daran sich an diese Richtlinien zu halten. Es wird IMMER Diskussionen geben, gerade was das Ausrichten von Typnamen oder auch '=' in Konstanten betrifft. Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Sherlock

[uligerhardt]

Zitat von Sherlock:

Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Is klar, ne. Du kennst meine Kollegen nicht.

[Sherlock]

Zitat von uligerhardt:

Zitat von Sherlock:

Wenn man sich dann auf einen "neutralen" Dritten berufen kann, ist der Käse gegessen.

Is klar, ne. Du kennst meine Kollegen nicht.

Das war mit Absicht sehr...einfach formuliert Ich hab ja schließlich auch diesen Kampf schon endlos ausgefochten. Selbst das Berufen auf "neutrale Dritte" hat nichts geholfen. Aber als Tipp, was wirklich hilft: Vor dem nächsten Commit einfach die komplette Unit formatieren lassen. Das ist dann nämlich ein weiterer Beweis für die normative Kraft des Faktischen

Sherlock

[uligerhardt]

Zitat von Sherlock:

Aber als Tipp, was wirklich hilft: Vor dem nächsten Commit einfach die komplette Unit formatieren lassen. Das ist dann nämlich ein weiterer Beweis für die normative Kraft des Faktischen

Das wird dann im Zweifelsfall schon wieder "korrigiert".

[mjustin]

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?

Im Delphi Style Guide ( http://edn.embarcadero.com/article/10280) ist es nicht zu finden.

Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Handelt es sich um eine Modeerscheinung?

[Stevie]

Im Delphi Source findet man das durchweg an vielen Stellen - wird aber nicht konsequent durchgezogen, aber schau mal in Classes.pas z.B.
Da Delphi nunmal nicht case sensitiv ist, bietet es sich an, Parameter zu prefixen, damit es keine potenziellen Namenskollisionen gibt.

[jaenicke]

Zitat von Benedikt Magnus:

Ich sortiere sie ein wenig, um es übersichtlicher zu gestalten:

Delphi-Quellcode:

uses
  { Standard }
    System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
[...]
  { Eigen }
    Unit_HTTP, Unit_HTTPS, Unit_Modulverarbeitung
  {};

Das mache ich auch so. Meistens als Delphi, 3rd-Party, Common (das sind unsere gemeinsamen Units für alle Projekte) und Project unterteilt. Wir benutzen auch Common als Namespace für diese gemeinsamen Units und einen projektspezifischen für die Units im Projekt. So kann dann eine Unit zum Beispiel heißen Common.Utils.StringTools.pas. Diese liegt dann im Verzeichnis common/utils im Repository. Und darin befindet sich eine gleichnamige Klasse TStringTools.
Interfaces liegen in einem Unterordner Interfaces und heißen dann z.B. Common.Interfaces.Utils.StringTools.pas.

So findet man zu Klassen und Interfaces schnell den Unitnamen und auch das Verzeichnis, in dem die Unit liegt.

Das finde ich sehr viel sinnvoller als ein Unit_ oder ähnliches voranzustellen. Denn dass es eine Unit ist, weiß ich auch so. Durch den Namespace Common weiß ich, dass es eine gemeinsame Unit ist, die nicht in das Projekt eingebunden sein muss um benutzt zu werden. (Die werden bei uns separat kompiliert.)
Ich habe also eine Mehrinformation, was bei Unit_ nicht der Fall ist. (Es sei denn du machst das genauso, nur mit Unit_ und Project_, was dann aber erst recht für Namespaces spräche.)

Vom Untereinanderschreiben halte ich wenig. Entweder sind es so wenige Units, dass man sie eh überblickt, oder es sind (z.B. in einem Datasnap oder FireDAC Datenmodul) so viele, dass sie untereinander geschrieben auch nicht leichter überschaubarer sind.

Dazu kommt, dass Error Insight ja anzeigt, wenn eine Unit fehlt. Leider kommt dazu ein Störrauschen von falschen Meldungen, aber wenn man sich dran gewöhnt hat, lassen sich diese recht gut von echten Meldungen unterscheiden. Wenn es zu viele falsche sind, bringt es natürlich nichts mehr.

Zitat von mjustin:

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?
[...]
Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Das wird im Quelltext der RTL und VCL durchaus häufig verwendet wie Stevie schon sagte, prominentestes Beispiel ist der Konstruktor einer Komponente:
http://docwiki.embarcadero.com/Libra...mponent.Create

Ich benutze das A auch, weil Parameter einer Methode so eindeutige Namen bekommen. Denn Test als Name des Paramaters würde zwar funktionieren, wäre aber sehr unsauber, weil die Property auch so heißt:

Delphi-Quellcode:

type
  TExample = class
  private
    FTest: Integer;
  public
    constructor Create(const ATest: Integer);
    property Test: Integer read FTest write FTest;
  end;

constructor TTest.Create(const ATest: Integer);
begin
  FTest := ATest;
end;

Und daher finde ich es sehr sinnvoll durchweg das A als Prefix zu verwenden.

[Sherlock]

Zitat von mjustin:

Woher kommt eigentlich dieses lästige und überflüssige A am Anfang von Parametern (z.B. "AValue")?

Im Delphi Style Guide ( http://edn.embarcadero.com/article/10280) ist es nicht zu finden.

Im Delphi Sourcecode - z.B. http://docwiki.embarcadero.com/Libra...ysUtils.Format - wird es nicht verwendet.

Handelt es sich um eine Modeerscheinung?

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können (nicht das Verfechter dieser Notation sowas tun würden, schon gar nicht unsere werten Mitforisten, ich denke aus dieser Not heraus wurde diese Notation geboren, das ist alles). Genauso gibt es ja noch die "kleines L" vor lokale Variablen Fraktion - ummm... li, anyone?. Ich halte es mit einem gesunden Mittelmaß: das "a" für Argument nehme ich gerne mit, das ist auch in den "offiziellen" Delphi Units so. Das "l" verkneif ich mir genauso wie den Typ der Variablen (egal ob infix oder postfix, sonst müsste ich mir bei ii jedesmal Gedanken machen, was nun Name und was Typ ist), Felder von Klassen bekommen wiederum ein "f" vorangestellt, dann weiß ich woran ich bin. Meiner Meinung nach muss ein Bezeichner lesbar sein, dann erübrigt sich auch ihm mitzugeben, daß er lokal ist und welchen Typ er hat. Letzteres erledigt die IDE ja ohnehin schon im Mouseover. Ersteres ergibt sich aus der Kürze der Methode.

Sherlock

[Uwe Raabe]

Zitat von Sherlock:

Aber es gibt tatsächlich Formatierungsrichtlinen von Borland...Codegear...Embarcadero

Der Vorteil dieses Styles ist einfach, daß sich auch die mitgelieferten Sourcen in der Regel daran orientieren - so wie viele andere Projekte auch. Man fühlt sich dort dann einfach wie zuhause. Jede davon abweichende Regel müsste schon eine sehr gute Begründung mitbringen, die deutlich über ein das ist mein persönlicher Geschmack oder das mache ich schon immer so hinaus geht. Und wenn schon jeder Standard besser ist als kein Standard, dann ist dieser Standard immerhin auch nicht schlechter als jeder andere Standard.

In der Regel steht bei mir der integrierte Formatter auch auf diesen (Default-)Einstellungen. Lediglich die Zeilenlänge setze ich passend zu den heute üblichen Widescreens auf einen höheren Wert. Durch die Kommandozeilenversion lassen sich auch problemlos ältere und fremde Sourcen ohne großen Aufwand anpassen.

Was mir noch fehlt ist eine Möglichkeit, die automatische Formatierung für eine Zeile oder einen Bereich ausser Kraft zu setzen. Es gibt halt immer mal wieder Ausnahmen.