Wo ist der Unterschied bei folgenden if-Abfragen?

    hallo Community,

    ich sehe oft zum Beispiel vom Sinn her diese beiden if-Abfragen:


    //"EquippedWeapon" ist hier ein Pointer, wenn also der Char eine Waffe in der Hand hat, dann kann gefeuert werden.


    if (EquippedWeapon)

    {

    FireWeapon();

    }


    //oder ich sehe auch das hier:


    if (EquippedWeapon == nullptr) return;


    FireWeapon();


    //beim zweiten if wird also gefragt, Wenn der Pointer ein Nullpointer ist, also leer ist, dann gib leere Funktion zurück, also lies nicht weiter.

    //Meine Frage nun, gibt es irgendeinen Grund warum es diese beiden unterschiedlichen Abfragen gibt? Eigentlich wollen doch beide auf das Gleiche hinaus. Warum vom Gedanken her einmal so und einmal so? Gibt es dort überhaupt einen Unterschied?

  • Zum Hilfreichsten Beitrag springen

    Hallo


    Im Grunde machen die dasselbe. Das erste if macht das Implizit per Boolean conversion. Bedeutet beim ersten wird ein nullptr einfach zu false.


    Was jetzt besser ist darfst du selbst entscheiden.

    Der Grund dafür ist wohl, dass das später eingeführt worden ist mit dem impliziten Boolean conversion. Die Sprache entwickelt sich ja auch immer weiter.


    // Edit: Oops Nicht genau genug gelesen :/. Dachte du meintest den Unterschied zwischen:

    Code
    if(EquippedWeapon){
}
und 
if(EquippedWeapon != nullptr) {
}

    Bei deiner eigentlichen Frage bin ich bei Tomarr. Manche bevorzugen das erste andere das Zweite.

    Diskutiert wird aber eher die Lesbarkeit.


    Gruss

    Das ist eine relativ philosophische Sache.


    Kommt aber noch darauf an wie man weiter machen möchte. Ersteres ermöglicht noch weitere Möglichkeiten, zum Beispiel das der Charakter alternativ zuschlagen soll oder so.


    Bei letzterem wird halt stumpf diese Funktion verlassen und nichts passiert.


    Wenn die beiden Beispiele, wie oben, so bleiben ist es in etwa das Gleiche. Ich glaube nicht, dass eins einen zeitlichen Vorteil gegenüber dem Anderen hat oder so.


    So wie ich es gelernt habe, ist allerdings auch schon 25 Jahre her, ist es allerdings recht unsauber eine Funktion quasi mit "Return" oder Schleifen mit "Break", oder was auch immer, abzuwürgen. Ob das noch immer Gültigkeit hat weiß ich allerdings auch nicht. Auch da gehen viele Meinungen auseinander. Heutige Compiler generieren aus solchem Code wahrscheinlich auch von sich aus schon das Richtige. Aber so tief bin ich in der Compilermaterie nun auch nicht drin.

    • Hilfreich
    Zitat von Tomarr

    So wie ich es gelernt habe, ist allerdings auch schon 25 Jahre her, ist es allerdings recht unsauber eine Funktion quasi mit "Return" oder Schleifen mit "Break", oder was auch immer, abzuwürgen. Ob das noch immer Gültigkeit hat weiß ich allerdings auch nicht. Auch da gehen viele Meinungen auseinander. Heutige Compiler generieren aus solchem Code wahrscheinlich auch von sich aus schon das Richtige. Aber so tief bin ich in der Compilermaterie nun auch nicht drin.

    Ja, das ganze hat heutzutage immer noch Gültigkeit. Hat aber eher etwas mit Clean-Coding zu tun, von daher komplett optional.

    An sich sollte man die returns einer Funktion minimal halten, sodass jemand der den Source Code ließt, im unteren Teil der Funktion herausfinden kann was zurückgegeben wird, ohne Gefahr zu laufen, dass ein return irgendwo mitten in der Funktion übersehen wird. Somit ist der Execution Flow deutlich einfacher verständlich.


    Es gibt ausnahmen, wenn es z.B. dafür sorgt dass man mehr Code schreiben muss nur um die Regel zu erfüllen, was natürlich auch nicht die Verständlichkeit verbessert.


    Eine Regel die ich selber noch nutze und mit dem Ausgangspost etwas zu tun hat:

    Falls ich checks habe, welche die Funktion abwürgen sollen, schreibe ich diese möglichst oben und breche die Funktion mit "return" ab, gerade wenn die alternative wäre über viele if-then-else Blöcke zu viele scopes zu erzeugen und somit wieder die Lesbarkeit verschlechtere.