Mozart53 Geschrieben 2. Januar 2022 Melden Share Geschrieben 2. Januar 2022 Was tut das return hier also was return es bei if !isGrounded? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
chrische5 Geschrieben 2. Januar 2022 Melden Share Geschrieben 2. Januar 2022 Hallo es beendet die Methode. Alles danach wird also nicht mehr ausgeführt. Christoph Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
malzbie Geschrieben 2. Januar 2022 Melden Share Geschrieben 2. Januar 2022 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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Sascha Geschrieben 3. Januar 2022 Melden Share Geschrieben 3. Januar 2022 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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
chrische5 Geschrieben 3. Januar 2022 Melden Share Geschrieben 3. Januar 2022 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Sascha Geschrieben 3. Januar 2022 Melden Share Geschrieben 3. Januar 2022 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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Recommended Posts
Archiviert
Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.