Bewährte Vorgehensweise bei der Rückkehr

Ich möchte wissen, was als bessere Art der Rückgabe angesehen wird, wenn ich eine ifErklärung habe.

Beispiel 1:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }
   else
   {
      myString = "Name " + myString;
      // Do something more here...
      return true;
   }
}

Beispiel 2:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }

   myString = "Name " + myString;
   // Do something more here...
   return true;
}

Wie Sie in beiden Beispielen sehen können, wird die Funktion zurückgegeben. true/falseIst es jedoch eine gute Idee, die elseAnweisung wie im ersten Beispiel zu platzieren, oder ist es besser, sie nicht zu platzieren?

Beispiel 2 ist als Schutzblock bekannt. Es ist besser geeignet, eine Ausnahme frühzeitig zurückzugeben / auszulösen, wenn ein Fehler aufgetreten ist (falscher Parameter oder ungültiger Zustand). Im normalen logischen Ablauf ist es besser, Beispiel 1 zu verwenden

Mein persönlicher Stil ist es, die Single iffür Guard Blocks und den if/ elseim eigentlichen Methodenverarbeitungscode zu verwenden.

In diesem Fall verwenden Sie die myString == nullals Schutzbedingung, daher würde ich eher das einzelne ifMuster verwenden.

Betrachten Sie Code, der etwas komplizierter ist:

Beispiel 1:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }
    else{
        //processing block
        myString = escapedString(myString);

        if (myString == "foo"){
            //some processing here
            return false;
        }
        else{
            myString = "Name " + myString;
            //other stuff
            return true;
        }
    }
}

Beispiel 2:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }

    //processing block
    myString = escapedString(myString);

    if (myString == "foo"){
        //some processing here
        return false;
    }
    else{
        myString = "Name " + myString;
        //other stuff
        return true;
    }
}

In Beispiel 1 haben sowohl der Guard als auch der Rest der Methode die Form if/ else. Vergleichen Sie dies mit Beispiel 2, in dem sich der Schutzblock in der einzelnen ifForm befindet, während der Rest der Methode die Form if/ elseverwendet. Ich persönlich finde Beispiel 2 einfacher zu verstehen, während Beispiel 1 unsauber und stark eingerückt aussieht.

Beachten Sie, dass dies ein erfundenes Beispiel ist und dass Sie else ifAnweisungen verwenden können, um es zu bereinigen, aber ich möchte den Unterschied zwischen Schutzblöcken und dem tatsächlichen Funktionsverarbeitungscode aufzeigen.

Ein anständiger Compiler sollte sowieso für beide die gleiche Ausgabe erzeugen. Der einzige Grund, den einen oder anderen zu verwenden, ist die persönliche Präferenz oder die Anpassung an den Stil des vorhandenen Codes.

persönlich bevorzuge ich die zweite Methode. Ich habe das Gefühl, es ist kürzer, hat weniger Einrückungen und ist leichter zu lesen.

Meine persönliche Praxis ist die folgende:

• Ich mag keine Funktionen mit mehreren Exit-Punkten, ich fand es schwierig, sie zu warten und zu befolgen. Code-Änderungen brechen manchmal die interne Logik, weil sie von Natur aus etwas schlampig sind. Wenn es sich um eine komplexe Berechnung handelt, erstelle ich zu Beginn einen Rückgabewert und gebe ihn am Ende zurück. Dies zwingt mich, die einzelnen If-else-, Switch- usw. Pfade sorgfältig zu befolgen und den Wert an den richtigen Stellen richtig einzustellen. Ich verbringe auch ein bisschen Zeit damit, zu entscheiden, ob ein Standardrückgabewert festgelegt oder beim Start nicht initialisiert werden soll. Diese Methode hilft auch, wenn sich die Logik oder der Rückgabewerttyp oder die Bedeutung ändert.

Zum Beispiel:

public bool myFunction()
{
   // First parameter loading
   String myString = getString();

   // Location of "quick exits", see the second example
   // ...

   // declaration of external resources that MUST be released whatever happens
   // ...

   // the return variable (should think about giving it a default value or not) 
   // if you have no default value, declare it final! You will get compiler 
   // error when you try to set it multiple times or leave uninitialized!
   bool didSomething = false;

   try {
     if (myString != null)
     {
       myString = "Name " + myString;
       // Do something more here...

       didSomething = true;
     } else {
       // get other parameters and data
       if ( other conditions apply ) {
         // do something else
         didSomething = true;
       }
     }

     // Edit: previously forgot the most important advantage of this version
     // *** HOUSEKEEPING!!! ***

   } finally {

     // this is the common place to release all resources, reset all state variables

     // Yes, if you use try-finally, you will get here from any internal returns too.
     // As I said, it is only my taste that I like to have one, straightforward path 
     // leading here, and this works even if you don't use the try-finally version.

   }

   return didSomething;
}

• Einzige Ausnahme: "Quick Exit" beim Start (oder in seltenen Fällen innerhalb des Prozesses). Wenn die reale Berechnungslogik eine bestimmte Kombination von Eingabeparametern und internen Zuständen nicht verarbeiten kann oder eine einfache Lösung ohne Ausführen des Algorithmus bietet, hilft es nicht, den gesamten Code in (manchmal tiefen) if-Blöcken zu kapseln. Dies ist ein "Ausnahmezustand", der nicht Teil der Kernlogik ist. Ich muss also aus der Berechnung aussteigen, sobald ich ihn entdeckt habe. In diesem Fall gibt es keine else-Verzweigung, im Normalfall wird die Ausführung einfach fortgesetzt. (Natürlich wird "Ausnahmezustand" besser durch das Auslösen einer Ausnahme ausgedrückt, aber manchmal ist es ein Overkill.)

Zum Beispiel:

public bool myFunction()
{
   String myString = getString();

   if (null == myString)
   {
     // there is nothing to do if myString is null
     return false;
   } 

   myString = "Name " + myString;
   // Do something more here...

   // not using return value variable now, because the operation is straightforward.
   // if the operation is complex, use the variable as the previous example.

   return true;
}

Die "one exit" -Regel hilft auch, wenn die Berechnung externe Ressourcen erfordert, die Sie freigeben müssen, oder wenn Sie vor dem Verlassen der Funktion einen Reset durchführen müssen. manchmal werden sie später während der Entwicklung hinzugefügt. Bei mehreren Ausgängen im Algorithmus ist es viel schwieriger, alle Zweige ordnungsgemäß zu erweitern. (Und wenn Ausnahmen auftreten, sollte die Freigabe / Rücksetzung ebenfalls in einen Endblock gestellt werden, um in seltenen Ausnahmefällen Nebenwirkungen zu vermeiden ...).

Ihr Fall scheint in die Kategorie "Quick Exit Before Real Work" zu fallen, und ich würde es so schreiben wie Ihre Version in Beispiel 2.

Ich bevorzuge es aus zwei Gründen, Schutzblöcke einzusetzen, wo immer ich kann:

1. Sie ermöglichen ein schnelles Verlassen unter bestimmten Bedingungen.
2. Das beseitigt die Notwendigkeit für komplexe und unnötige if-Anweisungen später im Code.

Im Allgemeinen bevorzuge ich Methoden, bei denen die Kernfunktionalität der Methode klar und minimal ist. Schutzblöcke helfen dabei, dies visuell umzusetzen.

Ich mag den "Fall Through" -Ansatz:

public bool MyFunction()
{
   string myString = GetString();

   if (myString != null)
   {
     myString = "Name " + myString;
     return true;
    }
    return false;
}

Die Aktion hat eine bestimmte Bedingung, alles andere ist nur die Standardrückgabe "fall through".

Wenn ich eine Single-If-Bedingung hätte, würde ich nicht zu viel Zeit damit verbringen, über den Stil nachzudenken. Aber wenn ich mehrere Schutzbedingungen habe, würde ich style2 vorziehen

Picuture dies. Angenommen, die Tests sind komplex und Sie möchten sie nicht wirklich in eine einzelne Bedingung mit ODER verknüpfen, um Komplexität zu vermeiden:

//Style1
if (this1 != Right)
{ 
    return;
}
else if(this2 != right2)
{
    return;
}
else if(this3 != right2)
{
    return;
}
else
{
    //everything is right
    //do something
    return;
}

gegen

//Style 2
if (this1 != Right)
{ 
   return;
}
if(this2 != right2)
{
    return;
}
if(this3 != right2)
{
    return;
}


//everything is right
//do something
return;

Hier gibt es zwei Hauptvorteile

1. Sie teilen den Code in einer einzigen Funktion in zwei visuell logische Blöcke auf: einen oberen Block mit Überprüfungen (Schutzbedingungen) und einen unteren Block mit ausführbarem Code.

2. Wenn Sie eine Bedingung hinzufügen / entfernen müssen, verringern Sie die Wahrscheinlichkeit, dass die gesamte if-elseif-else-Leiter durcheinander gebracht wird.

Ein weiterer kleiner Vorteil ist, dass Sie weniger Zahnspangensätze benötigen.

Das sollte eine Frage sein, die sich besser anhört.

If condition
  do something
else
  do somethingelse

drückt sich dann besser aus

if condition
  do something
do somethingelse

Für kleine Methoden ist es kein großer Unterschied, aber für größere zusammengesetzte Methoden kann es schwieriger zu verstehen sein, da es nicht richtig getrennt werden kann

Ich finde Beispiel 1 irritierend, weil die fehlende return-Anweisung am Ende einer value-return-Funktion sofort das "Wait, there there something wrong" -Flag auslöst. In solchen Fällen würde ich also mit Beispiel 2 fortfahren.

In der Regel handelt es sich jedoch um mehr, je nach Zweck der Funktion, z. B. Fehlerbehandlung, Protokollierung usw. Ich bin also mit Lorand Kedves der Antwort auf diese Frage und habe am Ende in der Regel einen Ausstiegspunkt, auch auf Kosten einer zusätzlichen Flagvariablen. Dies erleichtert in den meisten Fällen die Wartung und spätere Erweiterungen.

Wenn Ihre ifAnweisung immer zurückkehrt, gibt es keinen Grund, für den verbleibenden Code in der Funktion ein else zu verwenden. Dadurch werden zusätzliche Zeilen und zusätzliche Einrückungen hinzugefügt. Das Hinzufügen von unnötigem Code erschwert das Lesen, und wie jeder weiß, ist das Lesen von Code schwierig .

In Ihrem Beispiel ist das elsenatürlich unnötig, ABER ...

Wenn Sie schnell durch Codezeilen blättern, schauen Sie in der Regel auf die geschweiften Klammern und Einrückungen, um eine Vorstellung vom Code-Fluss zu erhalten. bevor sie sich tatsächlich auf den Code selbst festlegen. Wenn Sie also elseden zweiten Codeblock mit geschweiften Klammern und Einrückungen versehen, kann der Leser schneller erkennen, dass es sich um eine A- oder B-Situation handelt, in der der eine oder der andere Block ausgeführt wird. Das heißt, der Leser sieht die geschweiften Klammern und Einrückungen, BEVOR sie die returnnach dem Anfangsbuchstaben sehen if.

Meiner Meinung nach ist dies einer der seltenen Fälle, in denen das Hinzufügen eines redundanten Codes die Lesbarkeit des Codes erhöht und nicht verringert.

Ich würde Beispiel 2 vorziehen, da es sofort offensichtlich ist, dass die Funktion etwas zurückgibt . Aber noch mehr, ich würde es vorziehen, von einem Ort zurückzukehren, so:

public bool MyFunction()
{
    bool result = false;

    string myString = GetString();

    if (myString != nil) {
        myString = "Name " + myString;

        result = true;
    }

    return result;
}

Mit diesem Stil kann ich:

1. Sieh sofort, dass ich etwas zurückgebe.

2. Fangen Sie das Ergebnis jedes Funktionsaufrufs mit nur einem Haltepunkt ab.

Mein persönlicher Stil tendiert dazu zu gehen

function doQuery(string) {
    if (!query(string)) {
        query("ABORT");
        return false;
    } // else
    if(!anotherquery(string) {
        query("ABORT");
        return false;
    } // else
    return true;
}

Verwenden Sie die auskommentierten elseAnweisungen, um den Programmablauf anzuzeigen und lesbar zu halten. Vermeiden Sie jedoch massive Einrückungen, die bei vielen Schritten leicht über den Bildschirm gelangen können.

ich würde schreiben

public bool SetUserId(int id)
{
   // Get user name from id
   string userName = GetNameById(id);

   if (userName != null)
   {
       // update local ID and userName
       _id = id;
       _userNameLabelText = "Name: " + userName;
   }

   return userName != null;
}

Ich bevorzuge diesen Stil, weil es am offensichtlichsten ist, dass ich zurückkehren würde userName != null.

Meine Faustregel ist, entweder eine If-Return-Operation ohne Sonst (meistens für Fehler) oder eine vollständige If-else-If-Kette über alle Möglichkeiten durchzuführen.

Auf diese Weise vermeide ich es, zu ausgefeilt mit meiner Verzweigung umzugehen, da ich immer dann, wenn ich das tue, die Anwendungslogik in meine Ifs codiere, was die Pflege erschwert (z. B. wenn eine Aufzählung OK oder ERR ist und ich alle meine Ifs schreibe) Ausnutzen der Tatsache, dass! OK <-> ERR es nervt, dem Enum beim nächsten Mal eine dritte Option hinzuzufügen.)

In Ihrem Fall würde ich beispielsweise ein einfaches if verwenden, da "return if null" mit Sicherheit ein allgemeines Muster ist und Sie sich wahrscheinlich nicht um eine dritte Möglichkeit kümmern müssen (zusätzlich zu null / not null). in der Zukunft.

Wäre der Test jedoch etwas, das eine eingehendere Prüfung der Daten durchführt, würde ich mich stattdessen zu einem vollständigen Wenn-Andern irren.

Ich denke, es gibt eine Menge Fallstricke bei Beispiel 2, die später zu unbeabsichtigtem Code führen könnten. Zunächst einmal basiert der Fokus hier auf der Logik, die die Variable 'myString' umgibt. Aus diesem Grund sollten alle Tests von Bedingungen explizit in einem Codeblock durchgeführt werden, der bekannte und Standard- / unbekannte Logik berücksichtigt .

Was passiert, wenn später ungewollt Code in Beispiel 2 eingefügt wird, der die Ausgabe erheblich verändert hat?

   if (myString == null)
   {
      return false;
   }

   //add some v1 update code here...
   myString = "And the winner is: ";
   //add some v2 update code here...
   //buried in v2 updates the following line was added
   myString = null;
   //add some v3 update code here...
   //Well technically this should not be hit because myString = null
   //but we already passed that logic
   myString = "Name " + myString;
   // Do something more here...
   return true;

Ich denke, mit dem elseBlock, der unmittelbar auf die Überprüfung auf eine Null folgt, hätten Programmierer, die die Erweiterungen für die zukünftigen Versionen hinzugefügt haben, die gesamte Logik zusammenaddiert, da wir jetzt eine Folge von Logik haben, die für die ursprüngliche Regel nicht beabsichtigt war (Rückgabe, wenn der Wert ist) Null).

Ich bin fest davon überzeugt, dass einige der C # -Richtlinien zu Codeplex (Link dazu hier: http://csharpguidelines.codeplex.com/ ) Folgendes enthalten:

Msgstr "" "Fügen Sie einen beschreibenden Kommentar hinzu, wenn der Standardblock (else) leer sein soll. Wenn dieser Block nicht erreicht werden soll, lösen Sie eine InvalidOperationException aus, um zukünftige Änderungen zu erkennen, die durch die vorhandenen Fälle fallen könnten. Dies sorgt für besseren Code, weil Über alle Pfade, die der Code zurücklegen kann, wurde nachgedacht. "

Ich halte es für eine gute Programmierpraxis, bei Verwendung von Logikblöcken wie diesem immer einen Standardblock hinzuzufügen (if-else, case: default), um alle Codepfade explizit zu berücksichtigen und den Code keinen unbeabsichtigten logischen Konsequenzen auszusetzen.