Vordefinierte Parameter nur im Interface-Abschnitt?

[Codehunter]

Hallo!

Ich habe bisher immer vordefinierte Parameter sowohl im interface- als auch im implementation-Abschnitt angegeben:

Delphi-Quellcode:

interface

type
  TMyObject = class(TObject)
  public
    procedure Func(const Param: Integer = -1);
  end;

implementation

procedure TMyObject.Func(const Param: Integer = -1);
begin

end;

Das war sowas wie eine Gewohnheit. Nun ist mir aufgefallen, dass SHIFT-STRG-C im Implementation-Abschnitt eine abweichende Deklaration einfügt:

Delphi-Quellcode:

implementation

procedure TMyObject.Func(const Param: Integer);
begin

end;

Ist es gar nicht nötig, die Vorbelegung an beiden Stellen zu machen? War mir neu ...

[Sir Rufo]

Es ist noch nicht einmal nötig die Argumente im

Delphi-Quellcode:

implementation

Teil anzugeben ;)

Delphi-Quellcode:

interface

type
  TMyObject = class(TObject)
  public
    procedure Func(const Param: Integer = -1);
  end;

implementation

procedure TMyObject.Func;
begin

end;

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1342219)

Ist es gar nicht nötig, die Vorbelegung an beiden Stellen zu machen?

Ist tatsächlich so und erhöht damit natürlich die Wartbarkeit, weil Ändeurungen nur an einer Stelle gemacht werden müssen.

[Codehunter]

War das früher mal obligatorisch? Wenn man sich schon alte Gewohnheiten abgewöhnt will man ja wissen warum man das überhaupt so gemacht hat...

[bernau]

Zitat:

Zitat von Sir Rufo (Beitrag 1342221)

Es ist noch nicht einmal nötig die Argumente im

Delphi-Quellcode:

implementation

Teil anzugeben ;)

Delphi-Quellcode:

interface

type
  TMyObject = class(TObject)
  public
    procedure Func(const Param: Integer = -1);
  end;

implementation

procedure TMyObject.Func;
begin

end;

Aber nur, wenn Funktionen nicht overload sind. Oder?

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342222)

Zitat:

Zitat von Codehunter (Beitrag 1342219)

Ist es gar nicht nötig, die Vorbelegung an beiden Stellen zu machen?

Ist tatsächlich so und erhöht damit natürlich die Wartbarkeit, weil Ändeurungen nur an einer Stelle gemacht werden müssen.

Wobei es ganz angenehm ist, wenn ich in der Implementation die verfügbaren Parameter sofort sehe.

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1342225)

Zitat:

Zitat von Sir Rufo (Beitrag 1342221)

Es ist noch nicht einmal nötig die Argumente im

Delphi-Quellcode:

implementation

Teil anzugeben ;)

Delphi-Quellcode:

interface

type
  TMyObject = class(TObject)
  public
    procedure Func(const Param: Integer = -1);
  end;

implementation

procedure TMyObject.Func;
begin

end;

Aber nur, wenn Funktionen nicht overload sind. Oder?

Logisch, weil sonst die Eindeutigkeit nicht mehr gegeben ist. Darum ist das zwar möglich aber nicht ratsam ;)

[TiGü]

Zitat:

Zitat von Sir Rufo (Beitrag 1342221)

Es ist noch nicht einmal nötig die Argumente im

Delphi-Quellcode:

implementation

Teil anzugeben ;)

Delphi-Quellcode:

interface

type
  TMyObject = class(TObject)
  public
    procedure Func(const Param: Integer = -1);
  end;

implementation

procedure TMyObject.Func;
begin

end;

Genau darüber habe ich mich vor zwei Stunden beim Code umbauen auch gewundert.
Im

Delphi-Quellcode:

interface

-Teil hab ich einer Methode einen Parameter beschert und im

Delphi-Quellcode:

implementation

-Teil noch nicht angepasst und mich dann schwer gewundert das das Programm kompiliert UND funktioniert.

[himitsu]

In der Implementation lasse ich die Default-Parameter auch immer weg, dann ist das dort unten auch kürzer.
PS: Die Klassenvervollständigung tut das auch.
Genauso hab ich oben manchmal an jedem Parameter die Typdefinition und unten sind die dann mit Komma zusammengefasst. (wenn es bei Überladenen mehrere Versionen gibt, der Symmetrie)

Die Parameter schreibe ich aber dennoch in der Implementation.
Erstmal sieht man dann auch unten die Parameter und muß nicht erst hoch gucken oder das Code-Insight bemühen.
Dann gibt es einen Fall, wo Parameter immer unten stehen müssen. Also bei überladenen Methoden, denn nur so kann der Compiler die Methoden auseinander halten.
Und da ich gern alles einheitlich habe, stehen somit auch die anderen Parameter da.

Auch Dinge wie static, virtual oder inline muß man nur im Interface definieren.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1342224)

War das früher mal obligatorisch? Wenn man sich schon alte Gewohnheiten abgewöhnt will man ja wissen warum man das überhaupt so gemacht hat...

Um übersichtlichen Code zu haben. Das ist zumindest mein Grund. Dass man das auch weglassen kann, habe ich schon relativ früh gelesen.

Mir ist allerdings damals schon kein Grund eingefallen warum man diese Verwirrungstaktik betreiben sollte und die Parameter weglassen sollte. Ein Überblick über fremden Quelltext wird dadurch deutlich verzögert und auch in eigenem Quelltext ist es der Lesbarkeit deutlich abträglich.
Natürlich erkennt man Parameter in sauberem Quelltext zumindest an dem großen A als Prefix, aber den Typ sieht man daran dennoch nicht.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1342301)

Mir ist allerdings damals schon kein Grund eingefallen warum man diese Verwirrungstaktik betreiben sollte und die Parameter weglassen sollte. Ein Überblick über fremden Quelltext wird dadurch deutlich verzögert und auch in eigenem Quelltext ist es der Lesbarkeit deutlich abträglich.

Womit sich quasi schon zwangsläufig die Frage aufdrängt: Warum lässt die Klassenvervollständigung das dann per Default weg und kann man dieses Verhalten umkonfigurieren?

Zitat:

Zitat von jaenicke (Beitrag 1342301)

Natürlich erkennt man Parameter in sauberem Quelltext zumindest an dem großen A als Prefix, aber den Typ sieht man daran dennoch nicht.

Jetzt wo du das ansprichst, wirft das bei mir gleich die nächste Frage auf: Das "A" am Anfang jedes Parameternamen scheint wohl nur bei Prozeduren und Funktionen üblich zu sein, nicht jedoch bei Eventhandlern (procedure of object). Zumindest sieht man bei den allerwenigsten VCL-Klassen so ein führendes A in Eventhandlern.

Ich wünsche allen einen guten Start in die Woche.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1342331)

Womit sich quasi schon zwangsläufig die Frage aufdrängt: Warum lässt die Klassenvervollständigung das dann per Default weg und kann man dieses Verhalten umkonfigurieren?

Die Parameter werden ja gar nicht weggelassen - nur die Default-Werte.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342333)

Die Parameter werden ja gar nicht weggelassen - nur die Default-Werte.

Genau darauf bezog sich ja meine Eingangsfrage. Die Parameter wegzulassen hat Sir Rufo in den Raum gestellt, nicht ich ^^

[himitsu]

AOwner im Create, bei TComponent ... also doch mit A

Das ist nunmal keine "feste" Regel,
aber es gibt mehrere "Vorschlage" von irgendwelchen Delphi-Gurus, wie man es machen können sollte.

[Sherlock]

Das Create ist ja nicht so sehr ein Eventhandler wie ein Constructor...würde ich mal ganz keck behaupten.

Sherlock

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1342331)

Womit sich quasi schon zwangsläufig die Frage aufdrängt: Warum lässt die Klassenvervollständigung das dann per Default weg und kann man dieses Verhalten umkonfigurieren?

Ich meinte damit vor allem die Parameter an sich. Die Defaultwerte sind in der Tat nicht ganz so wichtig zum Verständnis, da alle Werte korrekt behandelt werden sollten.

Man erkennt daran ja vor allem so etwas wie -1 heißt "kein Eintrag" und größer oder gleich Null ist der Index oder die Nummer eines Eintrags. An der Stelle ist natürlich dann interessant, ob der Wert für "kein Eintrag" Null oder -1 ist, wenn das nicht anderswo dokumentiert ist, aber normalerweise sollte das auch im Quelltext sofort klar werden (anders als die Bedeutung und der Typ eines Parameters).

Trotzdem schreibe ich die Defaultwerte zu Dokumentationszwecken immer dazu.

[Codehunter]

Bzgl. Default-Werte im Implementation-Abschnitt: Ich habe jetzt mal eine Runde "gehirnt" warum ich das gewohnheitsmäßig so mache, dass die Defaults auch unten mit stehen. Die Erklärung ist so einfach wie banal: Ich habe die Klassenvervollständigung erst relativ spät überhaupt "entdeckt". Vorher habe ich die Routinen immer erst im interface-Teil definiert (mit Defaults) und dann einfach per Copy & Paste nach unten gebracht. So landeten die Defaults gleichermaßen in beiden Abschnitten.

Bzgl. dem "A" vor Parameternamen: Nehmen wir mal beispielsweise einen Klickhandler:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);

da heißt es ja auch nicht "ASender". Ein Blick in System.Classes.pas zeigt, dass das "A" in Eventhandler-Deklarationen tatsächlich eher die Ausnahme als die Regel ist, in Klassenmethoden und normalen Procedures dagegen genau umgekehrt. Das ändert aber nichts daran, dass man sich beim Codedesign an ein paar Gepflogenheiten halten sollte, auch wenn es technisch keine Notwendigkeit dazu gibt:

• Pointer mit einem "P" beginnen
• lokale Variablen mit einem "L"
• Klassen mit einem "T"
• Methodenparameter eben mit einem "A"
• Interfaces mit einen "I"
• Event-Properties mit einem "On"

Hab ich noch was vergessen? Ergänzungen wären willkommen :-)

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1342401)

Hab ich noch was vergessen? Ergänzungen wären willkommen :-)

• Felder in Klassen mit "F"
• Attribute ohne Prefix aber mit Postfix "Attribute"

Bei den Events gibt es auch noch ein breiteres Spektrum als lediglich das "On". Man denke nur an die Before- und After-Events bei DataSets.

Das "T" wird eigentlich auch für andere Typen verwendet, die nicht zwingend Klassen sein müssen.

Wie bei allen Regeln gibt es aber auch Ausnahmen. So würde ich einem

Delphi-Quellcode:

GermanAnsiString = type AnsiString(1252);

definitiv kein T voranstellen, um die Konsistenz mit anderen Typen dieser Art (z.B. UTF8String) zu erhalten.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342413)

Wie bei allen Regeln gibt es aber auch Ausnahmen.

Das ist klar, habe nie was anderes behauptet ^^

Zitat:

Zitat von Uwe Raabe (Beitrag 1342413)

Delphi-Quellcode:

GermanAnsiString = type AnsiString(1252);

Hihi damit ziehst du mich jetzt noch ne Weile auf, was? :lol: (Nein ich habe das Wawi noch nicht in die Tonne getreten. NOCH nicht...)