Styleguide für Parameteranordnung

[bernau]

Gibt es eigentlich ein Styleguide oder ein "best practice" für die Anordnung von Parametern?

Lieber so:

Delphi-Quellcode:

function getNames(aNames:TStrings;aBirthdayFrom:TDatetime;aBirthdayTo:TDatetime):boolean;

oder so:

Delphi-Quellcode:

function getNames(aBirthdayFrom:TDatetime;aBirthdayTo:TDatetime;aNames:TStrings):boolean;

Ich erwische mich immer wieder dabei, daß ich nicht wirklich eine klare Linie bei der Anordnung von Parametern habe. Wie ist es bei euch?

[bra]

Ich versuche die bei ähnlichen Funktionen in der selben Reihenfolge zu haben (ich habe z.B. bei diesen AnsiText-Funktionen ständig die Parameter vertauscht, da mal der SubText zuerst oder mal zuletzt kommt), ansonsten ist das doch sehr von den Parametern und deren Zweck abhängig.

[Neutral General]

Ich denke mal es ist üblicher, dass die Rückgabewerte hinten stehen (also Beispiel 2).
Ich glaube so mache ichs auch immer (wobei ich nie so genau darauf geachtet habe dass ich jetzt für diese Aussage meine Hand ins Feuer legen würde :mrgreen: )

[bernau]

Zitat:

Zitat von Neutral General (Beitrag 1345747)

Ich denke mal es ist üblicher, dass die Rückgabewerte hinten stehen (also Beispiel 2).

In der Regel mache ich es so. Aber dann kommt wieder eine Funktion in dem die Parameter mit Defaultwerte belegt sind.

Delphi-Quellcode:

function getNames(aNames:TStrings;aBirthdayFrom:TDatetime = 0;aBirthdayTo:TDatetime = 90000):boolean;

Dann muss ich das Ergebnis nach vorne setzen, weich ich die Default-Parameter ja ggf. weglassen möchte.

[Neutral General]

Na gut, da kannste dann halt auch nix machen :mrgreen:

[Der schöne Günther]

Generell ist es wirklich üblicher die Ausgabeparameter hinten zu haben. Auf SO fragt sich auch jemand über die Parameter-Ein/Ausgabe-Reihenfolge und wie Default-Parameterbelegungen damit zusammenhängen. [1]

Interessant da der Verweis aus den eigentlich sehr schönen Google C++ Style Guide - Das trifft ja auf Delphi alles ebenso zu. Das Ergebnis ist da dass Standard-Parameterbelegungen eh böse sind. Das Hauptargument ist dass der Parameter halt wirklich da ist und man keine Funktionszeiger damit belegen kann. Also so etwas:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses System.SysUtils;

procedure myProcedure(const someValue: Integer = 42);
begin
   WriteLn(someValue);
end;

var
   someProcedure: TProcedure;
begin
   someProcedure := myProcedure; // << E2009 Inkompatible Typen: 'Liste der Parameter ist unterschiedlich'
end;

end.

[1] http://stackoverflow.com/q/27934633/2298252

[Sherlock]

Ich liebe es Default-Werte für Parameter zu geben, zumindest vorübergehend. So kann ich eine Parameterliste erweitern, ohne daß der Code kaputt geht. Mit der Zeit ziehe ich dann alle Aufrufe nach und ergänze die fehlenden Parameter. Gibt es eigentlich eine FixInsight Prüfung für fehlende Parameter im Aufruf? Das wäre eventuell ne coole Sache.

Sherlock

[bernau]

Zitat:

Zitat von Sherlock (Beitrag 1345780)

Ich liebe es Default-Werte für Parameter zu geben, zumindest vorübergehend. So kann ich eine Parameterliste erweitern, ohne daß der Code kaputt geht. Mit der Zeit ziehe ich dann alle Aufrufe nach und ergänze die fehlenden Parameter.Sherlock

Deswegen habe ich früher auch gerne mit Defaultwerten gearbeitet.

Mittlerweile verwende ich aber eher "overload". Damit bin ich sogar noch etwas flexibler. Mit "deprecated" kann ich dann auf die veraltete Procedure hinweisen und nach und nach die alte Version entfernen. Ohne FixInsight.

Nachteil ist, daß ich den Default-Wert nicht wirklich im Interface-Bereich sehe und immer in die Implementation springen muss.

Delphi-Quellcode:

procedure myProcedure;overload;
procedure myProcedure(const someValue: Integer);overload;

implementation

procedure myProcedure;
begin
  myProcedure(42);
end;

procedure myProcedure(const someValue: Integer);
begin
   WriteLn(someValue);
end;

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1345766)

Delphi alles ebenso zu. Das Ergebnis ist da dass Standard-Parameterbelegungen eh böse sind. Das Hauptargument ist dass der Parameter halt wirklich da ist und man keine Funktionszeiger damit belegen kann. Also so etwas:

Klar geht das...

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses System.SysUtils;

type
  TDPTest = reference to procedure( const Arg: Integer = 42);

procedure myProcedure(const someValue: Integer = 42);
begin
  WriteLn(someValue);
end;

var
  someProcedure: TDPTest;
begin
  someProcedure := myProcedure;
  someProcedure;
end;

end.

Schon geht es...

[Mavarik]

Zitat:

Zitat von bernau (Beitrag 1345744)

Gibt es eigentlich ein Styleguide oder ein "best practice" für die Anordnung von Parametern?

Best Practice hab ich noch nicht gesehen...

Aber ich habe meine eigenen Regeln und daran halte ich mich...

AOwner / AParent 1. Parameter wenn es beide gibt Owner first.
Letzter Parameter (Wenn nicht default Parameter) dann ist es die Proc<T>
Out Parameter so weit nach hinten wie es geht.
Ansonsten
Reihenfolge gemäß Datengröße (Nicht unbedingt die eigentlich) Selbst wenn ein TObject nur ein Pointer ist und ein String ggf. als Daten übergeben werden...

TObject, String, Integer, Boolean // Da die Strings, Integer und Booleans i.d.R. die Kontrolle über die
Verwendung von TObject regeln..

Ausnahmen: Selecting String, selecting Interfaces Beispiel:

Delphi-Quellcode:

Procedure Foo(AKunde : TKunde; AInvoce : TProc<TKunden>;Const SaveWhere : String);

oder

Delphi-Quellcode:

Procedure Foo(AKunde : TKunde; ASaveLogic : ICanSaveKunden);

Aufruf:

Delphi-Quellcode:

begin
  if RESTServer 
    then begin
           Foo(LKunde,Procedure (AKunde : TKunden)
             begin
               AKunde.LastUser := AktUser;
               AKunde.Compress;
             end,'SaveAsJason');
         end
    else begin
           Foo(LKunde,Procedure (AKunde : TKunden)
             begin
               AKunde.LastUser := AktUser;
               AKunde.DataFormat := AktDoc2XML;
             end,'SaveAsStream');
         end;
end;

oder

Delphi-Quellcode:

var
  SaveAs : String;
begin
  if RESTServer
    then SaveAs := 'SaveAsJson'
    else SaveAs := 'SaveAsStream';

  Foo(LKunde,TAnyFactory.Default.CreateObj<ICanSaveKunden>(SaveAs));
end;

Mavarik

[Headbucket]

Hallo,

um nochmal die grundlegende Frage aufzugreifen.

Zitat:

Zitat von bernau (Beitrag 1345744)

Gibt es eigentlich ein Styleguide oder ein "best practice" für die Anordnung von Parametern?

Ja gibt es:

• Die wichtigsten/am meisten verwendeten Parameter (vom Aufrufenden) sollte zuerst dastehen. Die weniger wichtigen sollten weiter hinten kommen.
• Eingangsparameter sollten vor Ausgangsparametern stehen
• Allgemeinere Parameter sollten vor spezielleren Parametern stehen. Beispiel: SomeProc(APlanet, AContinent, ACountry, AState, ACity)

Ausnahmen bestätigen natürlich immer die Regel, sodass z.B. im Falle von Event-Handlern der Parameter "Sender" oft als erster Parameter angegeben wird.

Natürlich kann die "Wertung" auch von Person zu Person etwas unterschiedlich ausfallen. Seitdem ich jedoch diese Regeln befolge, so kann ich meine Entscheidung auch nach Jahren noch nachvollziehen.

Bei deinem Beispiel wäre somit generell der Name links in der Parameterliste und das Geburtsdatum rechts. Schließlich ist ein Name wichtiger als ein Geburtsdatum. In sämtlichen Formularen musst du zuerst deinen Namen eintragen und dann so Sachen wie das Geburtsdatum. Je nach Art der Methode KANN das natürlich auch mal anders sein.

Grüße
Karsten

[himitsu]

Selbst der Delphi-RTL-Code ist da uneins.
Manchmal ist der Out-Parameter vorne und manchmal hinten.

In Bezug auf Default-Parameter ist es zwar besser das Out vorne zu haben, aber ich mach es auch meistens hinten hin. :stupid:

Ich hab es oft hinten (VON>NACH), da Result auch hinten ist,
ABER das Result ist nur in der Definition hinten, aber im Aufruf ist es vorne. :lol:



PS:

Delphi-Quellcode:

Pos('x', 'xxx') > 0

Delphi-Quellcode:

ContainsStr('xxx', 'x')

Delphi-Quellcode:

MatchStr('x', ['xxx'])

:wall

Delphi-Quellcode:

Pos

ContainsStr MatchStr