Die "richtige" Sourcecode Formatierung?

[jaenicke]

Zitat von Sherlock:

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können

Das bezweifle ich. Ich habe ja das AOwner als Beispiel genannt. Da gibt es in der Klasse gleichzeitig noch Owner als Property. Und wenn man sich mal anschaut wo das noch auftauchte in älteren Quelltexten findest du noch weitere solche Fälle.

Einen Fall wie den von dir genannten sehe ich hingegen nirgends. Worauf beziehst du dich denn da? Im RTL oder VCL Quelltext meine ich.

Zitat von p80286:

Gute Anregung. Mir ist das uses oft zu unübersichtlich, das könnte helfen. Es muß ja nicht "common", "Herzstück" reicht auch.

Das heißt bei uns Common.Core.XYZ bzw. Frontend.Core.XYZ usw.
Das macht auch mehr Sinn als ein deutscher Bezeichner...

[Sherlock]

Zitat von jaenicke:

Zitat von Sherlock:

Vermutlich kommt das daher, um unsaubere Kapselung und reichlich globale Variablen weiter führen zu können

Das bezweifle ich. Ich habe ja das AOwner als Beispiel genannt. Da gibt es in der Klasse gleichzeitig noch Owner als Property. Und wenn man sich mal anschaut wo das noch auftauchte in älteren Quelltexten findest du noch weitere solche Fälle.

Einen Fall wie den von dir genannten sehe ich hingegen nirgends. Worauf beziehst du dich denn da? Im RTL oder VCL Quelltext meine ich.

Oh, ich habe das durchaus historisch gemeint. Nicht bezogen auf aktuell in der freien Wildbahn zu findende Quellen. Welchen Grund mag es sonst geben für einen Präfix, der ein Argument kennzeichnet? Heutzutage: keinen, außer "ham wir schon immer so gemacht". Vorausgesetzt natürlich, man hat ansonsten saubern Code (kurze Parameterlisten, kurze Methoden etc.)


Sherlock

[jaenicke]

Zitat von Sherlock:

Welchen Grund mag es sonst geben für einen Präfix, der ein Argument kennzeichnet? Heutzutage: keinen, außer "ham wir schon immer so gemacht". Vorausgesetzt natürlich, man hat ansonsten saubern Code (kurze Parameterlisten, kurze Methoden etc.)

Wie sieht denn deine Alternative für mein Beispiel aus?

// EDIT:

Zitat von Mavarik:

Wenn man nur Code für den deutschen Sprachraum schreibt mögen deutsche Bezeichner funktionieren.

Das bezweifle ich auch nicht, aber da die delphieigenen Bezeichner zwangsläufig englisch sind, läuft es immer auf ein Mischmasch aus Deutsch und Englisch hinaus...
Das macht den Code nicht übersichtlicher...

Beispiel aus freier Wildbahn:

Delphi-Quellcode:

if SchnellstartHaken.Checked or ZwangsstartAktiviert then
begin
  StartenKnopf.Click;
  Exit;
end;

[bra]

Zitat von jaenicke:

Wie sieht denn deine Alternative für mein Beispiel aus?

Eventuell so (nicht getestet):

Delphi-Quellcode:

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

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

Selbst wenn das funktioniert wäre das aber Programmier-Selbstmord, da sind die Fehler vorprogrammiert.

[Mavarik]

Dann doch lieber "neutral":

Delphi-Quellcode:

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

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

[jaenicke]

Zitat von Mavarik:

Dann doch lieber "neutral":

Delphi-Quellcode:

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

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

Dann musst du bei einem solchen Code aber jedesmal nachschauen was der Parameter bedeutet. Das ist finde ich die schlimmste Variante...
Vor allem, wenn es mehr als einen Parameter gibt...

[Stevie]

Bei mir würde das so aussehen (dass Parameter, Variablen und Felder mit nem kleinen Buchstaben anfangen, ist meine persönliche Note)

Delphi-Quellcode:

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

constructor TTest.Create(const test: Integer);
begin
  inherited Create;
  fTest := test;
end;

Nun mag jemand sagen, oje, da gibt es einen poteziellen Konflikt zwischen dem ctor parameter und der Eigenschaft. Nö, der parameter wird hier immer bevorzugt.
Natürlich müsste man innerhalb dieser Methode nun Self.Test schreiben, um an die Eigenschaft zu kommen, damit kann ich aber leben - da eher die Ausnahme.

Ich erspare mir nun mal ein Essay, warum automatic properties mit unterschiedlichen visibilities für getter und setter in C# oder anderen Sprachen so viel besser sind
als der ganze Extraklump mit explizit zu definierenden Feldern und der nahezu Unmöglichkeit, unterschiedliche Sichtbarkeiten für read und write anzugeben.

[Mavarik]

Zitat von jaenicke:

Dann musst du bei einem solchen Code aber jedesmal nachschauen was der Parameter bedeutet.

ok, bei normalen Procedure würde ich dir recht geben...

Bei Setter brauche ich das nicht, da es ja der Setter Wert ist..

Und i.d.R. steht im Setter sowieso..

Delphi-Quellcode:

begin
  FWhatever := AValue; // Value "wird" schon das richtige sein...
  ... // Code, warum ich überhaupt einen Setter brauche...
end;

[bernau]

Zitat von Mavarik:

Dann doch lieber "neutral":

Delphi-Quellcode:

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

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

(a)Value wird bei mir nur für Setter von Properties verwendet. Dort weis ich was Value für eine Bedeutung hat.

Ich würde an dieser Stelle im Create den Bezeichner "aTest" oder "aTestInit"verwenden. Ist ja eine Vorbelegung für fTest.

Das Property Test würde ich wie in dem Beispiel genau so deklarieren. Ohne Setter. Man sieht sofort, daß nur fTest behandelt wird und muss nicht schauen, ob im Setter noch weiteres ausgeführt wird.

[Mikkey]

Zitat von bra;1344784[DELPHI:

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

constructor TTest.Create(const FTest: Integer);
begin
Self.FTest := FTest;
end; [/DELPHI]

Selbst wenn das funktioniert wäre das aber Programmier-Selbstmord, da sind die Fehler vorprogrammiert.

Nichts für ungut, aber das entspricht in C# den (einigermaßen strikt festgelegten) Codierrichtlinien:

Code:

public ClassName(int bla, string blub) // Konstruktor von ClassName
{
    this.bla = bla;
    this.blub = blub;
}

Ich habe dabei noch nie einen Fehler, der auf dieses Vorgehen zurückgeht, erlebt. Der Compiler mault allerdings auch, wenn man das "this." vergisst. Das kann ich mangels Delphi nicht mehr ausprobieren.