Frage Ist es eine schlechte Übung, die Rückgabe innerhalb einer void-Methode zu verwenden?


Stellen Sie sich den folgenden Code vor:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Ist es in Ordnung, eine Rückgabe innerhalb einer void-Methode zu verwenden? Hat es eine Leistungseinbuße? Oder es wäre besser, einen Code wie diesen zu schreiben:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

75
2017-08-16 02:05


Ursprung


Antworten:


Eine Rückkehr in eine leere Methode ist nicht schlecht, ist eine gängige Praxis umkehren if Anweisungen, um die Verschachtelung zu reduzieren.

Durch weniger Verschachtelung Ihrer Methoden wird die Lesbarkeit und Wartbarkeit des Codes verbessert.

Wenn Sie eine void-Methode ohne eine return-Anweisung haben, erzeugt der Compiler immer eine Anweisung zurückgeben am Ende davon.


153
2017-08-16 02:11



Es gibt einen weiteren wichtigen Grund, Wächter zu verwenden (im Gegensatz zu verschachteltem Code): Wenn ein anderer Programmierer Ihrer Funktion Code hinzufügt, arbeiten sie in einer sichereren Umgebung.

Erwägen:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

gegen:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Stellen Sie sich vor, ein anderer Programmierer fügt die Zeile hinzu: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Offensichtlich ist dies ein einfacher Fall, aber der Programmierer hat dem Programm in der ersten (verschachtelten Code) Instanz einen Absturz hinzugefügt. Im zweiten Beispiel (früher Ausgang mit Wächtern) ist Ihr Code vor unbeabsichtigter Verwendung eines Nullverweises geschützt.

Sicher, ein großer Programmierer macht solche Fehler (oft) nicht. Aber Prävention ist besser als Heilung - wir können den Code so schreiben, dass diese potenzielle Fehlerquelle vollständig eliminiert wird. Die Verschachtelung erhöht die Komplexität, daher empfehlen Best Practices, Code zu refaktorieren, um die Verschachtelung zu reduzieren.


26
2017-08-16 06:52



Schlechte Praxis ??? Auf keinen Fall. In der Tat ist es immer besser, Validierungen durchzuführen, indem Sie frühestens dann von der Methode zurückkehren, wenn Validierungen fehlschlagen. Andernfalls würde es zu einer großen Menge verschachtelter Wenns und Else kommen. Eine frühzeitige Terminierung verbessert die Lesbarkeit des Codes.

Überprüfen Sie auch die Antworten auf eine ähnliche Frage: Sollte ich die Anweisung return / continue anstelle von if-else verwenden?


17
2017-08-16 03:36



Es ist keine schlechte Übung (aus allen bereits genannten Gründen). Je mehr Rückmeldungen Sie jedoch in einer Methode haben, desto eher sollte sie in kleinere logische Methoden aufgeteilt werden.


6
2017-08-16 04:35



Das erste Beispiel verwendet eine Guard-Anweisung. Von Wikipedia:

In der Computerprogrammierung ist eine Wache ein   Boolescher Ausdruck, der ausgewertet werden muss   auf wahr, wenn das Programm ausgeführt werden soll   weiter in der fraglichen Branche.

Ich denke, eine Reihe von Wächtern an der Spitze einer Methode zu haben, ist eine vollkommen verständliche Art zu programmieren. Es sagt im Grunde: "Führe diese Methode nicht aus, wenn eine davon wahr ist".

Also im Allgemeinen würde es das mögen:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Ich denke das ist dann viel lesbarer:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

4
2017-08-16 06:07



Es gibt keine Leistungseinbuße, jedoch ist der zweite Teil des Codes lesbarer und daher leichter zu warten.


2
2017-08-16 02:08



Es ist völlig in Ordnung und keine "Leistungseinbußen", aber schreiben Sie niemals eine 'if' Anweisung ohne Klammern.

Immer

if( foo ){
    return;
}

Es ist viel lesbarer; und Sie werden nie versehentlich annehmen, dass einige Teile des Codes in dieser Anweisung enthalten sind, wenn sie nicht vorhanden sind.


2
2017-08-16 02:16