Sollte eine Funktion nur eine return-Anweisung haben?

Gibt es gute Gründe, warum es besser ist, nur eine return-Anweisung in einer Funktion zu haben?

Oder ist es in Ordnung, von einer Funktion zurückzukehren, sobald dies logisch korrekt ist, was bedeutet, dass die Funktion möglicherweise viele return-Anweisungen enthält?

Ich habe oft mehrere Anweisungen am Anfang einer Methode, um für "einfache" Situationen zurückzukehren. Zum Beispiel:

public void DoStuff(Foo foo)
{
    if (foo != null)
    {
        ...
    }
}

... kann so besser lesbar gemacht werden (IMHO):

public void DoStuff(Foo foo)
{
    if (foo == null) return;

    ...
}

Also ja, ich denke es ist in Ordnung, mehrere "Austrittspunkte" von einer Funktion / Methode zu haben.

Niemand hat Code Complete erwähnt oder zitiert, also werde ich es tun.

17.1 Rückkehr

Minimieren Sie die Anzahl der Rückgaben in jeder Routine . Es ist schwieriger, eine Routine zu verstehen, wenn Sie beim Lesen unten nicht wissen, dass sie irgendwo darüber zurückkehrt.

Verwenden Sie eine Rückgabe, wenn dies die Lesbarkeit verbessert . In bestimmten Routinen möchten Sie die Antwort, sobald Sie sie kennen, sofort an die aufrufende Routine zurückgeben. Wenn die Routine so definiert ist, dass keine Bereinigung erforderlich ist, bedeutet eine nicht sofortige Rückgabe, dass Sie mehr Code schreiben müssen.

Ich würde sagen, es wäre unglaublich unklug, sich willkürlich gegen mehrere Austrittspunkte zu entscheiden, da ich festgestellt habe, dass die Technik in der Praxis immer wieder nützlich ist. Tatsächlich habe ich vorhandenen Code aus Gründen der Klarheit häufig auf mehrere Austrittspunkte umgestaltet . Wir können die beiden Ansätze folgendermaßen vergleichen:

string fooBar(string s, int? i) {
  string ret = "";
  if(!string.IsNullOrEmpty(s) && i != null) {
    var res = someFunction(s, i);

    bool passed = true;
    foreach(var r in res) {
      if(!r.Passed) {
        passed = false;
        break;
      }
    }

    if(passed) {
      // Rest of code...
    }
  }

  return ret;
}

Vergleichen Sie dies mit dem Code , wo mehrere Austrittspunkte sind zulässig: -

string fooBar(string s, int? i) {
  var ret = "";
  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 denke, letzteres ist wesentlich klarer. Soweit ich das beurteilen kann, ist die Kritik an mehreren Austrittspunkten heutzutage eine eher archaische Sichtweise.

Ich arbeite derzeit an einer Codebasis, in der zwei der Leute, die daran arbeiten, blind die "Single Point of Exit" -Theorie unterschreiben, und ich kann Ihnen sagen, dass es aus Erfahrung eine schrecklich schreckliche Praxis ist. Die Pflege von Code ist äußerst schwierig, und ich zeige Ihnen, warum.

Mit der "Single Point of Exit" -Theorie erhalten Sie unweigerlich Code, der so aussieht:

function()
{
    HRESULT error = S_OK;

    if(SUCCEEDED(Operation1()))
    {
        if(SUCCEEDED(Operation2()))
        {
            if(SUCCEEDED(Operation3()))
            {
                if(SUCCEEDED(Operation4()))
                {
                }
                else
                {
                    error = OPERATION4FAILED;
                }
            }
            else
            {
                error = OPERATION3FAILED;
            }
        }
        else
        {
            error = OPERATION2FAILED;
        }
    }
    else
    {
        error = OPERATION1FAILED;
    }

    return error;
}

Dies macht es nicht nur sehr schwierig, dem Code zu folgen, sondern sagt auch später, dass Sie zurückgehen und eine Operation zwischen 1 und 2 hinzufügen müssen. Sie müssen fast die gesamte Freaking-Funktion einrücken und viel Glück, um sicherzustellen, dass alles funktioniert Ihre if / else-Bedingungen und Klammern sind richtig aufeinander abgestimmt.

Diese Methode macht die Code-Wartung extrem schwierig und fehleranfällig.

Die strukturierte Programmierung besagt, dass Sie immer nur eine return-Anweisung pro Funktion haben sollten. Dies soll die Komplexität begrenzen. Viele Leute wie Martin Fowler argumentieren, dass es einfacher ist, Funktionen mit mehreren return-Anweisungen zu schreiben. Er präsentiert dieses Argument in dem klassischen Refactoring- Buch, das er geschrieben hat. Dies funktioniert gut, wenn Sie seinen anderen Ratschlägen folgen und kleine Funktionen schreiben. Ich stimme diesem Standpunkt zu und nur streng strukturierte Programmierpuristen halten sich an einzelne return-Anweisungen pro Funktion.

Wie Kent Beck bei der Erörterung von Schutzklauseln in Implementierungsmustern feststellt , hat eine Routine einen einzigen Ein- und Ausstiegspunkt ...

"war es, die Verwirrung zu vermeiden, die beim Ein- und Aussteigen aus vielen Orten in derselben Routine möglich war. Es war sinnvoll, wenn es auf FORTRAN- oder Assembler-Programme angewendet wurde, die mit vielen globalen Daten geschrieben wurden, bei denen selbst das Verstehen, welche Anweisungen ausgeführt wurden, harte Arbeit war. Mit kleinen Methoden und meist lokalen Daten ist es unnötig konservativ. "

Ich finde eine Funktion, die mit Schutzklauseln geschrieben wurde, viel einfacher zu befolgen als eine lange verschachtelte Reihe von if then elseAnweisungen.

In einer Funktion, die keine Nebenwirkungen hat, gibt es keinen guten Grund, mehr als eine einzige Rückgabe zu haben, und Sie sollten sie in einem funktionalen Stil schreiben. Bei einer Methode mit Nebenwirkungen sind die Dinge sequentieller (zeitindiziert), sodass Sie in einem imperativen Stil schreiben und die return-Anweisung als Befehl verwenden, um die Ausführung zu beenden.

Mit anderen Worten, wenn möglich, bevorzugen Sie diesen Stil

return a > 0 ?
  positively(a):
  negatively(a);

darüber

if (a > 0)
  return positively(a);
else
  return negatively(a);

Wenn Sie feststellen, dass Sie mehrere Ebenen verschachtelter Bedingungen schreiben, können Sie dies wahrscheinlich umgestalten, indem Sie beispielsweise eine Prädikatenliste verwenden. Wenn Sie feststellen, dass Ihr Wenn und Anderes syntaktisch weit voneinander entfernt ist, möchten Sie dies möglicherweise in kleinere Funktionen aufteilen. Ein bedingter Block, der mehr als einen Bildschirm voller Text umfasst, ist schwer zu lesen.

Es gibt keine feste Regel, die für jede Sprache gilt. So etwas wie eine einzige return-Anweisung macht Ihren Code nicht gut. Mit gutem Code können Sie Ihre Funktionen jedoch auf diese Weise schreiben.

Ich habe es in Codierungsstandards für C ++ gesehen, die ein Kater von C waren. Wenn Sie nicht über RAII oder eine andere automatische Speicherverwaltung verfügen, müssen Sie für jede Rückgabe bereinigen, was entweder Ausschneiden und Einfügen bedeutet der Bereinigung oder eines goto (logisch das gleiche wie "endlich" in verwalteten Sprachen), die beide als schlechte Form angesehen werden. Wenn Sie in C ++ oder einem anderen automatischen Speichersystem intelligente Zeiger und Sammlungen verwenden möchten, gibt es keinen triftigen Grund dafür, und es geht nur um Lesbarkeit und mehr um eine Beurteilung.

Ich lehne mich an die Idee, dass Rückgabeanweisungen in der Mitte der Funktion schlecht sind. Sie können return verwenden, um ein paar Schutzklauseln am oberen Rand der Funktion zu erstellen, und dem Compiler natürlich mitteilen, was er am Ende der Funktion ohne Probleme zurückgeben soll. Rückgaben in der Mitte der Funktion können jedoch leicht übersehen werden und können erschweren die Interpretation der Funktion.

Gibt es gute Gründe, warum es besser ist, nur eine return-Anweisung in einer Funktion zu haben?

Ja , es gibt:

• Der einzelne Ausstiegspunkt bietet einen hervorragenden Ort, um Ihre Nachbedingungen zu bestätigen.
• Es ist oft nützlich, einen Debugger-Haltepunkt auf die eine Rückgabe am Ende der Funktion setzen zu können.
• Weniger Renditen bedeuten weniger Komplexität. Linearer Code ist im Allgemeinen einfacher zu verstehen.
• Wenn der Versuch, eine Funktion auf eine einzige Rückgabe zu vereinfachen, Komplexität verursacht, ist dies ein Anreiz, kleinere, allgemeinere und leichter verständliche Funktionen zu überarbeiten.
• Wenn Sie in einer Sprache ohne Destruktoren arbeiten oder kein RAII verwenden, reduziert eine einzelne Rückgabe die Anzahl der Stellen, die Sie bereinigen müssen.
• Einige Sprachen erfordern einen einzigen Austrittspunkt (z. B. Pascal und Eiffel).

Die Frage wird oft als falsche Zweiteilung zwischen mehreren Rückgaben oder tief verschachtelten if-Anweisungen gestellt. Es gibt fast immer eine dritte Lösung, die sehr linear ist (keine tiefe Verschachtelung) und nur einen einzigen Austrittspunkt hat.

Update : Anscheinend fördern die MISRA-Richtlinien auch den Single-Exit .

Um es klar zu sagen, ich sage nicht, dass es immer falsch ist, mehrere Retouren zu haben. Angesichts ansonsten gleichwertiger Lösungen gibt es viele gute Gründe, die mit einer einzigen Rendite zu bevorzugen.

Ein einzelner Exit-Punkt bietet einen Vorteil beim Debuggen, da Sie einen einzelnen Haltepunkt am Ende einer Funktion festlegen können, um zu sehen, welcher Wert tatsächlich zurückgegeben wird.

Im Allgemeinen versuche ich, nur einen einzigen Austrittspunkt von einer Funktion zu haben. Es gibt jedoch Situationen, in denen dadurch tatsächlich ein komplexerer Funktionskörper als erforderlich erstellt wird. In diesem Fall ist es besser, mehrere Austrittspunkte zu haben. Es muss wirklich ein "Urteilsspruch" sein, der auf der resultierenden Komplexität basiert, aber das Ziel sollte so wenig Ausgangspunkte wie möglich sein, ohne die Komplexität und Verständlichkeit zu beeinträchtigen.

Nein, weil wir nicht mehr in den 1970ern leben . Wenn Ihre Funktion lang genug ist, dass mehrere Rückgaben ein Problem darstellen, ist sie zu lang.

(Abgesehen von der Tatsache, dass jede mehrzeilige Funktion in einer Sprache mit Ausnahmen ohnehin mehrere Austrittspunkte hat.)

Ich würde einen einzelnen Ausgang bevorzugen, es sei denn, dies erschwert die Dinge wirklich. Ich habe festgestellt, dass in einigen Fällen mehrere vorhandene Punkte andere wichtigere Entwurfsprobleme maskieren können:

public void DoStuff(Foo foo)
{
    if (foo == null) return;
}

Wenn ich diesen Code sehe, würde ich sofort fragen:

• Ist 'foo' jemals null?
• Wenn ja, wie viele Clients von 'DoStuff' rufen die Funktion jemals mit einem Null-Foo auf?

Abhängig von den Antworten auf diese Fragen kann es sein, dass

1. Die Prüfung ist sinnlos, da sie niemals wahr ist (dh es sollte eine Behauptung sein).
2. Die Prüfung ist sehr selten wahr und daher ist es möglicherweise besser, diese spezifischen Anruferfunktionen zu ändern, da sie wahrscheinlich sowieso andere Maßnahmen ergreifen sollten.

In beiden oben genannten Fällen kann der Code wahrscheinlich mit einer Zusicherung überarbeitet werden, um sicherzustellen, dass 'foo' niemals null ist und die relevanten Anrufer geändert werden.

Es gibt zwei weitere Gründe (speziell für C ++ - Code), bei denen mehrere tatsächlich negative Auswirkungen haben können. Sie sind Codegröße und Compiler-Optimierungen.

Bei einem Nicht-POD-C ++ - Objekt im Gültigkeitsbereich am Ende einer Funktion wird der Destruktor aufgerufen. Bei mehreren return-Anweisungen kann es vorkommen, dass sich unterschiedliche Objekte im Gültigkeitsbereich befinden und die Liste der aufzurufenden Destruktoren daher unterschiedlich ist. Der Compiler muss daher für jede return-Anweisung Code generieren:

void foo (int i, int j) {
  A a;
  if (i > 0) {
     B b;
     return ;   // Call dtor for 'b' followed by 'a'
  }
  if (i == j) {
     C c;
     B b;
     return ;   // Call dtor for 'b', 'c' and then 'a'
  }
  return 'a'    // Call dtor for 'a'
}

Wenn die Codegröße ein Problem darstellt, sollte dies vermieden werden.

Das andere Problem betrifft "Named Return Value OptimiZation" (auch bekannt als Copy Elision, ISO C ++ '03 12.8 / 15). Mit C ++ kann eine Implementierung den Aufruf des Kopierkonstruktors überspringen, wenn dies möglich ist:

A foo () {
  A a1;
  // do something
  return a1;
}

void bar () {
  A a2 ( foo() );
}

Wenn man den Code so nimmt, wie er ist, wird das Objekt 'a1' in 'foo' konstruiert und dann wird sein Kopierkonstrukt aufgerufen, um 'a2' zu konstruieren. Mit Copy Elision kann der Compiler jedoch 'a1' an derselben Stelle auf dem Stapel wie 'a2' erstellen. Es ist daher nicht erforderlich, das Objekt zu "kopieren", wenn die Funktion zurückkehrt.

Mehrere Exit-Punkte erschweren die Arbeit des Compilers, dies zu erkennen, und zumindest für eine relativ neue Version von VC ++ fand die Optimierung nicht statt, wenn der Funktionskörper mehrere Rückgaben hatte. Siehe Named Rückgabewert Optimierung in Visual C ++ 2005 für weitere Details.

Ein einziger Austrittspunkt verringert die zyklomatische Komplexität und damit theoretisch die Wahrscheinlichkeit, dass Sie Fehler in Ihren Code einfügen, wenn Sie ihn ändern. Die Praxis deutet jedoch eher darauf hin, dass ein pragmatischerer Ansatz erforderlich ist. Ich tendiere daher dazu, einen einzigen Austrittspunkt anzustreben, erlaube meinem Code jedoch, mehrere zu haben, wenn dies besser lesbar ist.

Ich zwinge mich, nur eine returnAnweisung zu verwenden, da dies gewissermaßen Codegeruch erzeugt. Lassen Sie mich erklären:

function isCorrect($param1, $param2, $param3) {
    $toret = false;
    if ($param1 != $param2) {
        if ($param1 == ($param3 * 2)) {
            if ($param2 == ($param3 / 3)) {
                $toret = true;
            } else {
                $error = 'Error 3';
            }
        } else {
            $error = 'Error 2';
        }
    } else {
        $error = 'Error 1';
    }
    return $toret;
}

(Die Bedingungen sind arbritary ...)

Je mehr Bedingungen, je größer die Funktion wird, desto schwieriger ist das Lesen. Wenn Sie also auf den Codegeruch eingestellt sind, werden Sie ihn erkennen und den Code umgestalten wollen. Zwei mögliche Lösungen sind:

• Mehrere Rückgaben
• Refactoring in separate Funktionen

Mehrere Rückgaben

function isCorrect($param1, $param2, $param3) {
    if ($param1 == $param2)       { $error = 'Error 1'; return false; }
    if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
    if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
    return true;
}

Separate Funktionen

function isEqual($param1, $param2) {
    return $param1 == $param2;
}

function isDouble($param1, $param2) {
    return $param1 == ($param2 * 2);
}

function isThird($param1, $param2) {
    return $param1 == ($param2 / 3);
}

function isCorrect($param1, $param2, $param3) {
    return !isEqual($param1, $param2)
        && isDouble($param1, $param3)
        && isThird($param2, $param3);
}

Zugegeben, es ist länger und etwas chaotisch, aber wir haben gerade dabei, die Funktion auf diese Weise umzugestalten

• eine Reihe von wiederverwendbaren Funktionen erstellt,
• machte die Funktion menschlicher lesbar, und
• Der Fokus der Funktionen liegt darauf, warum die Werte korrekt sind.

Ich würde sagen, Sie sollten so viele haben, wie erforderlich, oder alle, die den Code sauberer machen (wie z. B. Schutzklauseln ).

Ich persönlich habe noch nie gehört, dass "Best Practices" besagen, dass Sie nur eine Rückgabeerklärung haben sollten.

Zum größten Teil neige ich dazu, eine Funktion auf der Grundlage eines Logikpfads so schnell wie möglich zu verlassen (Schutzklauseln sind ein hervorragendes Beispiel dafür).

Ich glaube, dass mehrere Rückgaben normalerweise gut sind (in dem Code, den ich in C # schreibe). Der Single-Return-Stil ist ein Überbleibsel von C. Aber Sie codieren wahrscheinlich nicht in C.

Es gibt kein Gesetz, das nur einen Austrittspunkt für eine Methode in allen Programmiersprachen vorschreibt . Einige Leute bestehen auf der Überlegenheit dieses Stils, und manchmal erheben sie ihn zu einer "Regel" oder einem "Gesetz", aber dieser Glaube wird nicht durch Beweise oder Forschungen gestützt.

Mehr als ein Rückgabestil kann eine schlechte Angewohnheit in C-Code sein, wo Ressourcen explizit freigegeben werden müssen, aber Sprachen wie Java, C #, Python oder JavaScript, die Konstrukte wie automatische Garbage Collection und try..finallyBlöcke (und usingBlöcke in C #) enthalten ), und dieses Argument trifft nicht zu - in diesen Sprachen ist es sehr ungewöhnlich, dass eine zentralisierte manuelle Freigabe von Ressourcen erforderlich ist.

Es gibt Fälle, in denen eine einzelne Rückgabe besser lesbar ist, und Fälle, in denen dies nicht der Fall ist. Überprüfen Sie, ob dadurch die Anzahl der Codezeilen verringert, die Logik klarer oder die Anzahl der geschweiften Klammern und Einrückungen oder temporären Variablen verringert wird.

Verwenden Sie daher so viele Retouren, wie es Ihrer künstlerischen Sensibilität entspricht, da es sich um ein Layout- und Lesbarkeitsproblem handelt, nicht um ein technisches.

Ich habe in meinem Blog ausführlicher darüber gesprochen .

Es gibt gute Dinge über einen einzelnen Austrittspunkt zu sagen, genauso wie es schlechte Dinge über die unvermeidliche "Pfeil" -Programmierung zu sagen gibt , die sich daraus ergibt.

Wenn Sie während der Eingabevalidierung oder der Ressourcenzuweisung mehrere Exit-Punkte verwenden, versuche ich, alle "Fehler-Exits" sehr gut oben in der Funktion zu platzieren.

Sowohl der Spartan Programming- Artikel der "SSDSLPedia" als auch der Single Function Exit Point- Artikel des "Portland Pattern Repository's Wiki" enthalten einige aufschlussreiche Argumente. Natürlich gibt es auch diesen Beitrag zu beachten.

Wenn Sie beispielsweise wirklich einen einzelnen Exit-Punkt (in einer nicht ausnahmefähigen Sprache) möchten, um Ressourcen an einem einzigen Ort freizugeben, finde ich die sorgfältige Anwendung von goto gut. siehe zum Beispiel dieses eher erfundene Beispiel (komprimiert, um Bildschirmfläche zu sparen):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

Persönlich mag ich Pfeilprogrammierung im Allgemeinen nicht mehr als mehrere Austrittspunkte, obwohl beide nützlich sind, wenn sie richtig angewendet werden. Das Beste ist natürlich, Ihr Programm so zu strukturieren, dass es keines von beiden benötigt. Die Aufteilung Ihrer Funktion in mehrere Teile hilft normalerweise :)

Obwohl ich dabei ohnehin mehrere Austrittspunkte habe, wie in diesem Beispiel, wo einige größere Funktionen in mehrere kleinere Funktionen unterteilt wurden:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

Abhängig vom Projekt oder den Codierungsrichtlinien kann der größte Teil des Kesselplattencodes durch Makros ersetzt werden. Nebenbei bemerkt, wenn man es auf diese Weise aufschlüsselt, können die Funktionen g0, g1, g2 sehr einfach einzeln getestet werden.

Offensichtlich würde ich in einer OO- und ausnahmefähigen Sprache solche if-Anweisungen nicht verwenden (oder überhaupt, wenn ich mit wenig Aufwand damit durchkommen könnte), und der Code wäre viel einfacher. Und nicht pfeilig. Und die meisten nicht endgültigen Renditen wären wahrscheinlich Ausnahmen.

Zusamenfassend;

• Nur wenige Renditen sind besser als viele Renditen
• Mehr als eine Rückgabe ist besser als große Pfeile, und Schutzklauseln sind im Allgemeinen in Ordnung.
• Ausnahmen könnten / sollten wahrscheinlich die meisten "Schutzklauseln" ersetzen, wenn dies möglich ist.

Sie kennen das Sprichwort - Schönheit liegt in den Augen des Betrachters .

Einige schwören auf NetBeans und andere auf IntelliJ IDEA , andere auf Python und andere auf PHP .

In einigen Geschäften könnten Sie Ihren Job verlieren, wenn Sie darauf bestehen:

public void hello()
{
   if (....)
   {
      ....
   }
}

Die Frage dreht sich alles um Sichtbarkeit und Wartbarkeit.

Ich bin süchtig nach boolescher Algebra, um die Logik und den Gebrauch von Zustandsmaschinen zu reduzieren und zu vereinfachen. Es gab jedoch frühere Kollegen, die meinten, mein Einsatz von "mathematischen Techniken" beim Codieren sei ungeeignet, weil er nicht sichtbar und wartbar wäre. Und das wäre eine schlechte Praxis. Tut mir leid, die Techniken, die ich verwende, sind für mich sehr sichtbar und wartbar - denn wenn ich sechs Monate später zum Code zurückkehre, würde ich den Code klar verstehen und eher ein Durcheinander sprichwörtlicher Spaghetti sehen.

Hey Kumpel (wie ein ehemaliger Kunde sagte), mach was du willst, solange du weißt, wie man es repariert, wenn du es reparieren musst.

Ich erinnere mich, dass vor 20 Jahren ein Kollege von mir entlassen wurde, weil er eine so genannte agile Entwicklungsstrategie angewendet hatte. Er hatte einen akribischen inkrementellen Plan. Aber sein Manager schrie ihn an: "Sie können Funktionen nicht schrittweise für Benutzer freigeben! Sie müssen sich an den Wasserfall halten ." Seine Antwort an den Manager war, dass die schrittweise Entwicklung genauer auf die Bedürfnisse des Kunden zugeschnitten sein würde. Er glaubte an die Entwicklung für die Kundenbedürfnisse, aber der Manager glaubte an die Codierung nach "Kundenanforderungen".

Wir sind häufig schuldig, Datennormalisierungs-, MVP- und MVC- Grenzen überschritten zu haben. Wir inline anstatt eine Funktion zu konstruieren. Wir nehmen Abkürzungen.

Persönlich glaube ich, dass PHP eine schlechte Praxis ist, aber was weiß ich. Alle theoretischen Argumente laufen darauf hinaus, einen Satz von Regeln zu erfüllen

Qualität = Präzision, Wartbarkeit und Rentabilität.

Alle anderen Regeln treten in den Hintergrund. Und natürlich verblasst diese Regel nie:

Faulheit ist die Tugend eines guten Programmierers.

Ich neige dazu, Schutzklauseln zu verwenden, um früh zurückzukehren und ansonsten am Ende einer Methode zu beenden. Die Einzeleintritts- und -ausgangsregel hat historische Bedeutung und war besonders hilfreich, wenn es sich um Legacy-Code handelte, der für eine einzelne C ++ - Methode mit mehreren Rückgaben (und vielen Fehlern) 10 A4-Seiten umfasste. In jüngerer Zeit wird empfohlen, Methoden klein zu halten, wodurch Mehrfachausgänge die Verständnisimpedanz verringern. Im folgenden von oben kopierten Kronoz-Beispiel lautet die Frage, was in // Rest des Codes vorkommt ... ?:

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;
}

Mir ist klar, dass das Beispiel etwas erfunden ist, aber ich wäre versucht, die foreach- Schleife in eine LINQ-Anweisung umzuwandeln, die dann als Schutzklausel betrachtet werden könnte. Auch hier ist die Absicht des Codes in einem konstruiertes Beispiel nicht ersichtlich und Funktion () Wirkung eine andere Seite hat in der verwendet wird oder kann das Ergebnis // Rest des Code ... .

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;
}

Ein guter Grund, den ich mir vorstellen kann, ist die Code-Wartung: Sie haben einen einzigen Ausgangspunkt. Wenn Sie das Format des Ergebnisses ändern möchten, ... ist die Implementierung viel einfacher. Zum Debuggen können Sie dort einfach einen Haltepunkt setzen :)

Trotzdem musste ich einmal in einer Bibliothek arbeiten, in der die Codierungsstandards "eine Rückgabeanweisung pro Funktion" vorschrieben, und ich fand es ziemlich schwierig. Ich schreibe viel numerischen Berechnungscode, und es gibt oft "Sonderfälle", so dass der Code ziemlich schwer zu befolgen war ...

Mehrere Austrittspunkte sind für ausreichend kleine Funktionen ausreichend - dh eine Funktion, die insgesamt auf einer Bildschirmlänge angezeigt werden kann. Wenn eine lange Funktion ebenfalls mehrere Austrittspunkte enthält, ist dies ein Zeichen dafür, dass die Funktion weiter zerlegt werden kann.

Das heißt, ich vermeide Mehrfach-Exit-Funktionen, es sei denn, dies ist absolut notwendig . Ich habe Schmerzen von Fehlern verspürt, die auf eine streunende Rückkehr in einer dunklen Linie in komplexeren Funktionen zurückzuführen sind.

Ich habe mit schrecklichen Codierungsstandards gearbeitet, die Ihnen einen einzigen Exit-Pfad aufgezwungen haben, und das Ergebnis sind fast immer unstrukturierte Spaghetti, wenn die Funktion alles andere als trivial ist - Sie haben am Ende viele Pausen und fahren fort, die Ihnen nur im Weg stehen.

Ein einziger Austrittspunkt - alle anderen Dinge sind gleich - macht den Code 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 einzelne 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, diese in mehrere kleinere Funktionen mit einem einzigen Austrittspunkt aufzuteilen.

Meine übliche Richtlinie besteht darin, nur eine return-Anweisung am Ende einer Funktion zu haben, es sei denn, die Komplexität des Codes wird durch Hinzufügen weiterer Anweisungen erheblich verringert. Tatsächlich bin ich eher ein Fan von Eiffel, das die einzige Rückgaberegel erzwingt, indem es keine Rückgabeanweisung hat (es gibt nur eine automatisch erstellte 'Ergebnis'-Variable, in die Sie Ihr Ergebnis einfügen können).

Es gibt sicherlich Fälle, in denen Code mit mehreren Rückgaben klarer dargestellt werden kann als die offensichtliche Version ohne sie. Man könnte argumentieren, dass mehr Nacharbeit erforderlich ist, wenn Sie eine Funktion haben, die zu komplex ist, um ohne mehrere return-Anweisungen verständlich zu sein, aber manchmal ist es gut, in solchen Dingen pragmatisch zu sein.

Wenn Sie am Ende mehr als ein paar Retouren erhalten, stimmt möglicherweise etwas mit Ihrem Code nicht. Ansonsten würde ich zustimmen, dass es manchmal schön ist, von mehreren Stellen in einem Unterprogramm zurückkehren zu können, insbesondere wenn dadurch der Code sauberer wird.

Perl 6: Schlechtes Beispiel

sub Int_to_String( Int i ){
  given( i ){
    when 0 { return "zero" }
    when 1 { return "one" }
    when 2 { return "two" }
    when 3 { return "three" }
    when 4 { return "four" }
    ...
    default { return undef }
  }
}

wäre besser so geschrieben

Perl 6: Gutes Beispiel

@Int_to_String = qw{
  zero
  one
  two
  three
  four
  ...
}
sub Int_to_String( Int i ){
  return undef if i < 0;
  return undef unless i < @Int_to_String.length;
  return @Int_to_String[i]
}

Beachten Sie, dass dies nur ein kurzes Beispiel ist

Ich stimme für Single Return am Ende als Richtlinie. Dies hilft bei einer allgemeinen Code-Bereinigung ... Sehen Sie sich beispielsweise den folgenden Code an ...

void ProcessMyFile (char *szFileName)
{
   FILE *fp = NULL;
   char *pbyBuffer = NULL:

   do {

      fp = fopen (szFileName, "r");

      if (NULL == fp) {

         break;
      }

      pbyBuffer = malloc (__SOME__SIZE___);

      if (NULL == pbyBuffer) {

         break;
      }

      /*** Do some processing with file ***/

   } while (0);

   if (pbyBuffer) {

      free (pbyBuffer);
   }

   if (fp) {

      fclose (fp);
   }
}

Dies ist wahrscheinlich eine ungewöhnliche Perspektive, aber ich denke, dass jeder, der glaubt, dass mehrere return-Anweisungen bevorzugt werden sollen, noch nie einen Debugger auf einem Mikroprozessor verwenden musste, der nur 4 Hardware-Haltepunkte unterstützt. ;-);

Während die Probleme mit "Pfeilcode" vollständig korrekt sind, scheint ein Problem, das bei Verwendung mehrerer return-Anweisungen zu verschwinden scheint, in der Situation zu liegen, in der Sie einen Debugger verwenden. Sie haben keine bequeme Sammelposition, um einen Haltepunkt zu setzen, um sicherzustellen, dass Sie den Ausgang und damit die Rückgabebedingung sehen.

Je mehr return-Anweisungen Sie in einer Funktion haben, desto komplexer ist diese eine Methode. Wenn Sie sich fragen, ob Sie zu viele return-Anweisungen haben, möchten Sie sich möglicherweise fragen, ob diese Funktion zu viele Codezeilen enthält.

Aber nicht, es ist nichts falsch an einer / mehreren return-Anweisungen. In einigen Sprachen ist es eine bessere Praxis (C ++) als in anderen (C).