Styleguide für Parameteranordnung

[bernau]

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

Lieber so:

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

oder so:

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 )

[bernau]

Zitat von Neutral General:

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.

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

[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 von 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.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 von Der schöne Günther:

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 von bernau:

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:

Procedure Foo(AKunde : TKunde; AInvoce : TProc<TKunden>;Const SaveWhere : String); oder
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