Was ist bevorzugt: geschachtelte If's oder Exit Sub / Function?
Vor kurzem habe ich an altem vb.net-Code gearbeitet und während der Code-Überprüfung wurde empfohlen, nicht Sub-Funktion zu verwenden, sondern alle Funktionen in IF-Anweisungen zu verschachteln.
Als ich anfing, mich zu entwickeln, tat ich es instinktiv (Nest the IF's), es erschien mir nicht nur logischer, es schien auch weniger verwirrend.
Aber irgendwann arbeitete ich mit einem Team zusammen, das verschachtelte IFs als "böse" behandelte, und daher wurde Exitsubs / Funktionen, die mir gesagt wurden, bevorzugt. Ich bin mir ziemlich sicher, dass sie MS-Best-Practice-Material produziert haben, um dies zu untermauern.
Diese Frage ist also für erfahrene Entwickler, welcher Weg wird wirklich bevorzugt? Wenn Sie eine Antwort geben, können Sie auch Ihre Quellen angeben, oder erwähnen Sie einfach, dass dies eine Präferenz ist, die von Ihrem Team / Unternehmen / Personal bevorzugt wird, und geben Sie Gründe an.
Vielen Dank im Voraus.
BEARBEITEN wie gewünscht: Codebeispiele
Exit Sub:
%Vor%Verschachtelte IFs:
%Vor%6 Antworten
Wie David in seinem Kommentar hervorgehoben hat, verschachtelte if-Anweisungen können die Komplexität Ihres Codes erhöhen.
Stellen Sie sich den folgenden (vereinfachten) Code vor:
%Vor%Oder das Folgende
%Vor%Wenn Ihre Bedingungen komplexer werden, macht das Zurückgeben viel leichter zu verstehen, dass Ihr Code unter bestimmten Bedingungen nichts tut und Ihren Code lesbarer macht.
Ansonsten müssen Sie alle Funktionen lesen und die verschachtelten ifs analysieren, um zu sehen, dass nichts getan wurde.
Beim Code-Peer-Review wurde empfohlen, Exit Sub / Function nicht zu verwenden, sondern alle Funktionen in IF-Anweisungen zu verschachteln.
Das ist ein schrecklicher Ratschlag. So einfach ist das. Ignoriere es. Tatsächlich ist das Gegenteil der Fall, besonders in Situationen, in denen verschachtelte Einrückungen erforderlich sind oder wenn Sie Ihre Parameter auf Gültigkeit überprüfen und möglicherweise vorzeitig beenden: der Code in Ihrer Frage ist ein gutes Beispiel dafür. Verwenden Sie früher als exit hier.
Dafür gibt es keine "offizielle" Quelle (was wäre offiziell?), aber es ist unter guten Programmierern ziemlich Konsens, wobei eine sehr kleine Minderheit dagegen ist. Weitere Informationen hierzu finden Sie in der Diskussion über Programmierer .
Ich würde jedoch empfehlen, Return anstelle von Exit {Sub|Function} zu verwenden.
Wie bei allem "hängt es davon ab." Beide können unangenehm sein, wenn sie im falschen Kontext verwendet werden.
Zum Beispiel, was überprüft conditionMetFromAnotherFunction() ? Wenn es eine Art von erforderlicher Vorbedingung für DoSomeWork() überprüft, dann würde ich sogar bis zu einer Ausnahme gehen, anstatt nur die Funktion still zu verlassen. ArgumentException wäre nützlich, wenn es beispielsweise die Gültigkeit eines an die Funktion übergebenen Arguments überprüft. Ruhig aussteigen scheint nicht richtig, wenn etwas im System tatsächlich falsch war.
Für die geschachtelten Bedingungen ist das definitiv chaotisch. Beachten Sie die Faustregel, dass eine Funktion "eine Sache tun sollte". Diese Bedingung zu überprüfen, ist eine Sache. In diesem Fall sollte 'Method work starts here nichts anderes als ein Aufruf einer anderen Methode sein, die tatsächlich die Arbeit erledigt. Es sollte nicht viele Codezeilen sein, die alle in einer großen Bedingung eingeschlossen sind. Und Die Funktionsnamen sollten genau wiedergeben, was sie gerade tun. Also wäre dies DoWorkIfConditional (im erfundenen Beispiel) und die andere Methode wäre DoWork .
Es ist OK, dass die Funktionen die Bedingungen vor der Arbeit überprüfen. Wenn die Voraussetzungen nicht erfüllt sind, würde ich eine Ausnahme in Erwägung ziehen. Aber das hängt von der tatsächlichen Logik der Anwendung ab, die in diesem Beispiel nicht wirklich vermittelt wird.
Ich empfehle Ihnen, die Antworten here
Zusammenfassend: Einfacher Eintrag / Einfacher Ausgang in Sprachen entwickelt, in denen Sie mehrere Einstiegspunkte für eine Funktion haben und Sie können auch an verschiedene Positionen im Code zurückgeben. Es wurde fälschlicherweise so interpretiert, dass nur ein Punkt im Code zulässig ist, an den Sie von zurückgeben können.
Die "best practice", 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, damit der Kontrollfluss bestehen muss durch dort. Dies gilt nicht für Sprachen, die auf .NET oder JVM basieren.
Insgesamt ist Code normalerweise lesbarer, wenn Sie mehrere Returns verwenden dürfen.
IMO verschachtelte if's sind ein sehr schneller Weg zum entsetzlichen Spaghetti-Code. Allgemein gesagt, wenn Sie Ihren Code tief verschachteln, dann versuchen Sie zu viel in Ihrer Methode zu arbeiten und werden höchstwahrscheinlich vom Refactoring in kleinere Teile profitieren.
Nachdem gesagt wurde, dass es manchmal nicht vermieden werden kann, gibt es keine Antwort für alle.