Die "richtige" Sourcecode Formatierung?

[p80286]

Zitat von jaenicke:

Delphi-Quellcode:

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

Sahne, das erinnert doch an die Siemensianische "Warzentaste". Allerdings weiß der nicht Eingeweihte sofort, welche Teile des Codes vom Programmierer stammen. Ob ein Franzose damit gut leben kann, steht auf einem anderen Blatt.
Mir ist letztlich eine "Diffusion List" (ohne jeden erhellenden Kontext) über den Weg gelaufen. Nach etwas suchen bin ich dann auf eine "Mailing List" gestoßen, was wiederum ganz gut zu den vorhandenen Daten passte.

Zitat:

Une liste de diffusion ou liste de distribution (mailing list en anglais, abrégée en ML)

Also Englisch um jeden Preis ist auch nicht der Weisheit letzter Schluß.

Gruß
K-H

[Sherlock]

Hmmm, also zunächst sollte der folgende eherne Grundatz festgehalten werden: "Ausnahmen bestätigen die Regel". Dann wollte ich gerne noch darauf hinweisen, daß ich später schrieb, daß ich aber durchaus Argumente als solche kennzeichne, einfach um mit dem Emba-Style (der wiederum, wie bereits erwähnt, nichts über Argumente sagt) übereinzustimmen.

Sherlock

[Benedikt Magnus]

Zitat von jaenicke:

Delphi-Quellcode:

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

Wie von p80286 schon angedeutet, lässt solcher Code sofort erkennen, ob die entsprechenden Teile eigener Code sind. Und das sehe ich als großen Vorteil an sowohl für die Fehlerfindung als auch die Übersichtlichkeit des Codes.
Mal ganz davon abgesehen: Auf Deutsch zu programmieren erleichtert es einem enorm, Namenskonflikte zu vermeiden!

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

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

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

[bernau]

Zitat von jaenicke:

Beispiel aus freier Wildbahn:

Delphi-Quellcode:

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

Das Beispiel ist zwar etwas übertrieben, aber im meinem Quellcode kommen oft deutsche Bezeichner vor. Weniger in common units als im Projekt selber. Grade wenn es um Fachbegriffe geht, bleibe ich bei deutschen Begriffen.

Meine Komponenten würde ich nun nicht unbedingt SchnellstartHaken nennen. Aber ChkSchnellstart kommt bei mir durchaus vor.

[jaenicke]

Zitat von Mavarik:

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

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

Dann sind wir uns ja einig, deshalb hatte ich im Beispiel auch den Konstruktor genommen. Bei Settern ist das sicher richtig, die ruft man ja in der Regel außerdem ohnehin nicht direkt auf. Mir ging es ja um die Hilfetexte, die beim Aufruf sagen welche Parameter nötig sind.

Zitat von Mikkey:

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.

In Delphi mault der Compiler nur, wenn du die Parameter als const deklarierst. Ansonsten darfst du auch problemlos dem Parameter einen Wert zueisen.

Zitat von bernau:

Das Beispiel ist zwar etwas übertrieben, aber im meinem Quellcode kommen oft deutsche Bezeichner vor.

Wie ich geschrieben habe:
Das ist aus freier Wildbahn, nicht von mir ausgedacht...