Result einer Funktion "Stil Frage"

[Jonas Shinaniganz]

Wo grade schonmal eine ähnliche Frage gestellt wurde:
Ich habe mich schon vor einger Zeit gefragt, was in diesem Fall lesbarer / besser ist:

Delphi-Quellcode:

function Min(X1, X2 : Integer) : Integer;
begin
  if (X1 < X2) then
    Min := X1
  else
    Min := X2;
end;

VS

Delphi-Quellcode:

function Min(X1, X2 : Integer) : Integer;
begin
  if (X1 < X2) then
    Result := X1
  else
    Result := X2;
end;

Zum Einen ist es ersichtlich, was jetzt gesetzt wird. Also X1 ist Min finde Ich gut. Zum Anderen schreiben aber viele immer Result := ...

Wie ist dazu die Meinung?

[Sir Rufo]

IMHO würde ich immer Result nehmen.

Jeder Andere (ausser mir) der meinen Code dann mal lesen sollte sieht auf einen Blick, dass es sich hier um den Rückgabewert der Funktion handelt

[Bernhard Geyer]

Alte Pascal-Compiler kannten das result-Schlüsselwort noch nicht.
Die alte Version mit dem Funktionsnamen ist mehr oder minder nur noch wegen der Altkompatiblität vorhanden.

[Uwe Raabe]

Es gibt noch einen anderen Vorteil bei der Verwendung von Result: man kann es auch als Wert verwenden - das geht bei dem Funktionsnamen nicht.

Delphi-Quellcode:

Function Sum(const Values: TBytes): Integer;
var
  B: Byte;
begin
  Result := 0;
  for B in Values do
    Result := Result + B;  // bei Sum statt Result meckert hier der Compiler
end;

Sollte die Funktion keine Parameter haben meckert er zwar nicht, produziert aber eine wohl unerwünschte Rekursion.

[sx2008]

3. Vorteil: man kann die Funktion problemlos umbenennen.
Verwendet man den Funktionsnamen anstelle von Result bringt jede Umbenennung einer Funktion zunächst Compilerfehler und dann lästiges Editieren mit sich.

[himitsu]

Result ist immer besser.
- man erkennt genau was gemeint ist
- man kann mit dem Namen nicht rechnen
- und wenn man die Funktion umbenennt, muß man das auch immer mit anpassen

Rechnen:
In C wird meisten eine Hilfsvariable verwendet und das Ergebnis erst am Ende an RETURN übergeben.

In Delphi is t das nicht nötig, da man Result direkt verwenden kann, jedenfalls dann, wenn man nicht den funktionsnamen verwendet.

Delphi-Quellcode:

Result := 132;
...
Result := Result * 2;
...
end;

Am Beispiel von dem schon genannten "Sum" würd man schnell in einer Endlosschleife landen.
Denn "sum" wird nur bei Zuweisungen als Funktionsergebnis genommen und sonst ist es ein Aufruf.

Delphi-Quellcode:

Function Sum(const Values: TBytes): Integer;
var
  B: Byte;
begin
  Sum := 0;  // entspricht Result :O 0;
  for B in Values do
    Sum := Sum + B;  // hier würde es aber Result := Sum + B; sein, also ein rekursiver Aufruf
end;

Ach ja: Und das Result muß grundsätzlich immer initialisiert werden, selbst wenn man denkt, daß es bei String, dyn. Array und Interface auch ohne funtioniert.
Glaubt mir einfach, dem ist nicht so.

[Uwe Raabe]

Zitat von himitsu:

Am Beispiel von dem schon genannten "Sum" würd man schnell in einer Endlosschleife landen.
Denn "sum" wird nur bei Zuweisungen als Funktionsergebnis genommen und sonst ist es ein Aufruf.

Delphi-Quellcode:

Function Sum(const Values: TBytes): Integer;
var
  B: Byte;
begin
  Sum := 0;  // entspricht Result :O 0;
  for B in Values do
    Sum := Sum + B;  // hier würde es aber Result := Sum + B; sein, also ein rekursiver Aufruf
end;

Das führt zunächst erstmal zu einem Compilerfehler, da Sum einen Parameter erwartet. Nur bei parameterlosen Funktionen kommt es zur Rekursion mit baldigem Stackoverflow (und nicht zu einer Endlosschleife).

[Furtbichler]

Zitat von himitsu:

Und das Result muß grundsätzlich immer initialisiert werden, selbst wenn man denkt, daß es bei String, dyn. Array und Interface auch ohne funtioniert.

Und ich dachte immer, das lokale Variablen grundsätzlich initialisiert werden müssen, egal ob sie Result heißen oder Strings oder Interfaces sind. Selbst der Delph-Compiler dürfte doch eine Warnung ausgeben, oder?

[Jonas Shinaniganz]

Okay die Frage hat sich gelohnt Danke!

[himitsu]

Zitat von Furtbichler:

Und ich dachte immer, das lokale Variablen grundsätzlich initialisiert werden müssen, egal ob sie Result heißen oder Strings oder Interfaces sind. Selbst der Delph-Compiler dürfte doch eine Warnung ausgeben, oder?

Nein, der Delphi-Compiler gibt leider nicht immer eine Warnung aus.

Praktisch gesehn werden "einfach" lokale Variablen nicht initialisiert, was man, im Prinzip, als eine Optimierung ansehn kann. (unnötiger/doppelter compilerseitiger Code)

Aber gewisse Typen, speziell alle, welche von Delphi eine automatische Speicherverwaltung bekommen haben, werden prinzipbedingt auch automatisch initialisiert, dazu zählen "lange" Strings (AnsiString, RawByteString, UTF8String und UnicodeString, aber keine ShortString), WideString, dynamische Arrays, Interfaces und der Variant, bzw. OleVariant.

Denn für die speicherverwaltung braucht es unbedingt einen definierten Grundzustand.


Der Witz daran ist, daß ein Result nicht immer eine lokale Variable ist, so wie man es vermuten könnte,
denn bei oben genannten Typen, ist das in Wirklichkeit kein "Result", sondern ein Var-Parameter.
Delphi verwaltet dieses Typen, sowie auch "größere" Array und Records als zusätzlichen Var-Parameter, welcher an die anderen Parameter angehängt wird.
Wo schlußendlich die "Result-Variable herkommt, ist also unklar.

Leider geht der Compiler nun, bei den genannten Typen, davon aus, daß diese somit initialisiert sind.
Welches aber gerade beim Result nicht "direkt" stimmt.

Die externe Variable wurde ordnungsgemäß initialisiert, aber, in Bezug auf die folgende Funktion, ist dieses nicht der Fall.

Delphi-Quellcode:

function Test: string;
begin
  Result := Result + 'abc';
end;

for i := 0 to 2 do
  S := Test;
ShowMessage(S);

Was für eine Message angezeigt wird, kannst du gerne ausprobieren.
(wenn es nicht zufällig eine Schleife wäre, dann wäre es natürlich "meistens" das 'abc')