Was ist vorzuziehen: verschachtelte If's oder Exit Sub / Funktion?

Question

Kürzlich habe ich auf Legacy vb.net-Code arbeiten und während Code Peer Review wurde empfohlen, nicht zu verwenden Exit Sub / Funktion, sondern um alle Funktionen in IF-Anweisungen zu verschachteln.

Als ich anfing zu entwickeln, habe ich es instinktiv so gemacht (Nest the IF's), es schien nicht nur logischer, sondern auch weniger verwirrend.

Irgendwann arbeitete ich jedoch mit einem Team zusammen, das verschachtelte IFs als "böse" betrachtete, und so wurde mir gesagt, dass Exit subs / functions bevorzugt würden. Ich bin mir ziemlich sicher, dass sie einige MS-Best-Practice-Materialien erstellt haben, um dies zu bestätigen.

Diese Frage richtet sich also an erfahrene Entwickler: Welcher Weg ist wirklich vorzuziehen? Wenn Sie eine Antwort geben, geben Sie bitte auch Ihre Quellen an, oder erwähnen Sie einfach, dass Ihr Team / Ihr Unternehmen / Ihre Person dies bevorzugt, und nennen Sie die Gründe.

Vielen Dank im Voraus.

EDIT wie gewünscht: Code-Beispiele

Exit Sub :

Private Sub DoSomeWork()
 if not conditionMetFromAnotherFunction() then
      exit Sub 
 end if

 'Method work starts here
End Sub

Verschachtelte IFs:

Private Sub DoSomeWork()
 if conditionMetFromAnotherFunction() then
     'Method work starts here
 end if
End Sub

Answer 1

Wenn Sie Ihre Funktionen nicht frühzeitig beenden, werden Sie einen Punkt erreichen, an dem Ihr Code so aussieht:

Niemand kann mir sagen, dass dies ein besserer Stil ist, als frühzeitig von einer Veranstaltung zurückzukehren.

Answer 2

Bei der Code-Peer-Review wurde empfohlen, keine Exit Sub/Funktion zu verwenden, sondern alle Funktionen in IF-Anweisungen zu verschachteln.

Das ist ein furchtbarer Ratschlag. So einfach ist das. Ignorieren Sie ihn. Das Gegenteil ist in der Regel der Fall, insbesondere in Situationen, in denen eine verschachtelte Einrückung erforderlich ist oder in denen Sie Ihre Parameter auf Gültigkeit prüfen und möglicherweise vorzeitig abbrechen: Der Code in Ihrer Frage ist ein gutes Beispiel dafür. Do hier den vorzeitigen Ausstieg nutzen.

Es gibt keine "offizielle" Quelle dafür (was wäre schon offiziell?), aber es ist ein ziemlicher Konsens unter guten Programmierern, mit einer sehr kleinen Minderheit, die sich dagegen ausspricht. Weitere Diskussionen darüber finden Sie in der Diskussion über Programmierer .

Ich würde jedoch empfehlen, die Return anstelle von Exit {Sub|Function} .

Answer 3

Wie David in seinem Kommentar erwähnt hat, können verschachtelte if-Anweisungen die Komplexität des Codes erhöhen.

Stellen Sie sich den folgenden (vereinfachten) Code vor:

Private Sub DoSomeWork()
    if conditionMetFromAnotherFunction() then
        if conditionDependantUponPreviousCondition then
            ' Do the work
        end if
    end if
End Sub

Oder die folgenden

Private Sub DoSomeWork()
    if not conditionMetFromAnotherFunction()
        return
    else if not conditionDependantUponPreviousCondition 
        return
    end if

    ' If we're here, everything's all good
    ' Do the work...
End Sub

Wenn Ihre Bedingungen komplexer werden, macht die Rückgabe es viel einfacher zu verstehen, dass Ihr Code unter bestimmten Bedingungen nichts tut, und macht Ihren Code besser lesbar.

Andernfalls müssen Sie die gesamte Funktion lesen und die verschachtelten Wenns mental analysieren, um zu sehen, dass nichts passiert ist.

Answer 4

Wie bei allem, "es kommt darauf an". Beides kann geschmacklos sein, wenn es im falschen Kontext verwendet wird.

Zum Beispiel, was ist conditionMetFromAnotherFunction() überprüfen? Wenn es eine Art geforderte Vorbedingung prüft für DoSomeWork() dann würde ich sogar so weit gehen, eine Ausnahme durchlaufen zu lassen, anstatt die Funktion einfach stillschweigend zu beenden. ArgumentException wäre z.B. nützlich, um die Gültigkeit eines an die Funktion übergebenen Arguments zu überprüfen. Ein stilles Beenden scheint nicht richtig zu sein, wenn etwas im System tatsächlich falsch war.

Bei den verschachtelten Konditionalen ist das definitiv unordentlich. Beachten Sie die Faustregel, dass eine Funktion sollte "eine Sache tun". Diesen Zustand zu überprüfen ist eine Sache. In diesem Fall ist also die 'Method work starts here sollte nichts weiter sein als ein Aufruf einer anderen Methode, die die eigentliche Arbeit erledigt. Sie sollte pas viele Codezeilen sein, die alle in eine große Bedingung verpackt sind. Et Die Funktionsnamen sollten genau wiedergeben, was sie tun. Diese würde also lauten DoWorkIfConditional (in dem erfundenen Beispiel) und die andere Methode wäre DoWork .

Es ist in Ordnung, wenn die Funktionen die Vorbedingungen prüfen, bevor sie ihre Arbeit tun. Wenn die Vorbedingungen nicht erfüllt sind, würde ich in Erwägung ziehen, eine Ausnahme auszulösen. Aber das hängt von der tatsächlichen Logik der Anwendung ab, die in diesem Beispiel nicht wirklich vermittelt wird.

Answer 5

Ich schlage vor, die Antworten zu lesen aquí für eine gute Zusammenfassung zu diesem Thema.

Zusammengefasst: Einzelne Einfahrt / Einzelne Ausfahrt die in Sprachen entwickelt wurden, in denen es mehrere Einstiegspunkte für eine Funktion gibt und in denen man auch zurückkehren kann zu verschiedenen Positionen im Kodex. Es wurde fälschlicherweise so interpretiert, dass es nur einen Punkt im Code gibt, an dem man zurückkehren kann von .

Die "beste Praxis", nur eine Return/Exit-Anweisung in einem Unterprogramm zu verwenden, stammt aus Sprachen mit expliziter Heap-Verwaltung, bei der die Ressourcen eines Unterprogramms am Ende des Unterprogramms freigegeben werden, so dass der Kontrollfluss dort durchlaufen werden muss. Dies gilt nicht für Sprachen, die auf .NET oder JVM basieren.

Insgesamt ist der Code in der Regel besser lesbar, wenn Sie die Möglichkeit haben, mehrere Rückgaben zu verwenden.