Die "richtige" Sourcecode Formatierung?

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