Was tut das return; hier?

[Mozart53]

Was tut das return hier also was return es bei if !isGrounded?

[chrische5]

Hallo

 

es beendet die Methode. Alles danach wird also nicht mehr ausgeführt. 

 

Christoph 

[malzbie]

Es sorgt dafür, dass sofort aus der FixedUpdate zurück gesprungen wird und somit die nachfolgende Abfrage und das setzen der Velocity gar nicht erst bearbeitet wird.

Alles, was da in dieser FixedUpdate drin steht, soll nur gemacht werden wenn isGrounded true ist. Sonst eben nicht.

[Sascha]

Beides, was @chrische5 und @malzbie sagen ist genau richtig, daher das Folgende nur als kleine Ergänzung.

Das ist eine Stil-Entscheidung. Man kann schreiben:

if (isGrounded)
{
  bla
  bla
  bla
  bla
  bla
  bla
  bla
}

oder eben

if (!isGrounded)
{
  return;
}
  
bla
bla
bla
bla
bla
bla
bla

Im zweiten Fall ist das blabla eine Stufe weniger eingerückt (also weiter links). Wenn du dir vorstellst, dass du nicht nur isGrounded abfragst, sondern evtl noch mehr Sachen, die aber nicht alle in eine Abfrage können, dann sieht das z.B. so aus:

if (isGrounded)
{
  bla

  if (wasAnderes)
  {
    bla
    bla

    if (nochWas)
    {
      bla
      bla
    }

    bla
    bla
  }
}

Da wird's gerne mal unübersichtlich. Deswegen ist Einrückung verringern eine nette Sache. Das "Early Return" ist aber auch nicht unproblematisch. Manchmal schaut man eine Methode an und denkt "oh, in diesem Update wird also xy ausgeführt". Und man merkt nicht, dass weiter oben irgendwo im Code ein return versteckt ist, sodass xy doch nicht immer ausgeführt wird. Man sagt dazu auch, dass "der Kontrollfluss verschleiert" wird. Es ist also schwerer, auf einen Blick zu erkennen, wo der Code "langgeht".

Alles Vor- und Nachteile. Funktionieren tut der Code auf beide Arten gleichermaßen gut. Es geht hier nur um Vorlieben beim Thema Lesbarkeit.

[chrische5]

Hallo

 

Also ich versuche immer nur ein return pro Methode zu haben oder eben die Methode immer durchlaufen zu lassen, wenn es keinen Rückgabwert gibt. Ist für mich viel übersichtlicher.

 

Christoph

[Sascha]

Jau, so hab ich's auch an der Uni gelernt. Early Outs find ich aber okay, wenn sie ausschließlich am Anfang der Methode eingesetzt werden. Es sei denn, man hat so eine Methode, in der man lauter verschachtelte Fälle nacheinander abarbeitet.

if (a)
{
  bla
  return;
}

if (b) // und damit implizit nicht a
{
  bla
  return;
}

if (c)  // und damit implizit nicht a und nicht b
{
  bla
  return;
}

Aber wie gesagt, Geschmackssache. Hauptsache, man entscheidet sich für einen Stil im Projekt und zieht ihn im Projekt konsistent durch.