Sollte eine Funktion nur eine Rückgabeanweisung haben?

Question

Gibt es gute Gründe, warum es besser ist, nur eine Rückgabeanweisung in einer Funktion zu haben?

Oder ist es in Ordnung, aus einer Funktion zurückzukehren, sobald dies logisch korrekt ist, d.h. es kann viele Return-Anweisungen in der Funktion geben?

Answer 1

Ich neige dazu, Guard-Klauseln zu verwenden, um früh zurückzukehren und ansonsten am Ende einer Methode zu beenden. Die Regel des einmaligen Ein- und Ausstiegs hat historische Bedeutung und war besonders hilfreich, als es um alten Code ging, der für eine einzige C++-Methode mit mehreren Rückgaben (und vielen Fehlern) 10 A4-Seiten umfasste. In jüngerer Zeit hat es sich bewährt, die Methoden klein zu halten, so dass mehrere Ausgänge weniger ein Hindernis für das Verständnis darstellen. In dem folgenden Kronoz-Beispiel, das wir oben kopiert haben, geht es um die Frage, was in //Rest des Codes... ?:

void string fooBar(string s, int? i) {

  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

Ich weiß, dass das Beispiel etwas konstruiert ist, aber ich wäre versucht, die foreach Schleife in eine LINQ-Anweisung, die dann als Schutzklausel betrachtet werden könnte. Auch hier ist die Absicht des Codes in einem erfundenen Beispiel nicht ersichtlich und someFunction() kann eine andere Nebenwirkung haben oder das Ergebnis kann in der Praxis verwendet werden. // Rest des Codes... .

if (string.IsNullOrEmpty(s) || i == null) return null;
if (someFunction(s, i).Any(r => !r.Passed)) return null;

Geben Sie die folgende überarbeitete Funktion:

void string fooBar(string s, int? i) {

  if (string.IsNullOrEmpty(s) || i == null) return null;
  if (someFunction(s, i).Any(r => !r.Passed)) return null;

  // Rest of code...

  return ret;
}

Answer 2

Ein guter Grund, den ich mir vorstellen kann, ist die Wartung des Codes: Sie haben einen einzigen Ausgangspunkt. Wenn Sie das Format des Ergebnisses ändern wollen,..., ist es einfach viel einfacher zu implementieren. Außerdem kann man zum Debuggen dort einfach einen Haltepunkt setzen :)

Abgesehen davon musste ich einmal in einer Bibliothek arbeiten, in der die Codierungsstandards "eine Rückgabeanweisung pro Funktion" vorschrieben, und ich fand das ziemlich schwierig. Ich schreibe viel Code für numerische Berechnungen, und da gibt es oft "Sonderfälle", so dass der Code am Ende ziemlich schwer zu folgen war...

Answer 3

Mehrere Exit-Points sind in Ordnung, wenn die Funktion klein genug ist, d. h. wenn sie auf einem Bildschirm in ihrer Gesamtheit betrachtet werden kann. Wenn eine längere Funktion ebenfalls mehrere Exit-Points enthält, ist das ein Zeichen dafür, dass die Funktion weiter zerlegt werden kann.

Deshalb vermeide ich Funktionen mit mehreren Ausgängen sofern nicht unbedingt erforderlich . Ich habe den Schmerz von Fehlern gespürt, die auf eine verirrte Rückkehr in einer obskuren Zeile in komplexeren Funktionen zurückzuführen sind.

Answer 4

Ein einziger Exit-Point macht den Code - unter sonst gleichen Bedingungen - deutlich lesbarer. Aber es gibt einen Haken: beliebte Konstruktion

resulttype res;
if if if...
return res;

ist eine Fälschung, "res=" ist nicht viel besser als "return". Es hat eine einzige Return-Anweisung, aber mehrere Punkte, an denen die Funktion tatsächlich endet.

Wenn Sie eine Funktion mit mehreren Rückgaben (oder "res="s) haben, ist es oft eine gute Idee, sie in mehrere kleinere Funktionen mit einem einzigen Exit-Point zu unterteilen.

Answer 5

Ich habe mit schrecklichen Codierungsstandards gearbeitet, die einem einen einzigen Ausstiegspfad aufzwangen, und das Ergebnis ist fast immer unstrukturiertes Spaghetti, wenn die Funktion alles andere als trivial ist - am Ende hat man viele Unterbrechungen und Fortsetzungen, die einfach im Weg sind.