Frage

In Anbetracht des folgende Code-Schnipsel, gibt es keinen nennenswerten Unterschied?

public boolean foo(int input) {
   if(input > 10) {
       doStuff();
       return true;
   }
   if(input == 0) {
       doOtherStuff();
       return true;
   }

   return false;
}

vs.

public boolean foo(int input) {
   if(input > 10) {
      doStuff();
      return true;
   } else if(input == 0) {
      doOtherStuff();
      return true;
   } else {
      return false;
   }
}

Oder wäre das einzige Ausfahrt Prinzip besser hier mit diesem Stück Code ...

public boolean foo(int input) {
   boolean toBeReturned = false;
   if(input > 10) {
      doStuff();
      toBeReturned = true;
   } else if(input == 0) {
      doOtherStuff();
      toBeReturned = true;
   }

   return toBeReturned;
}

Gibt es einen wahrnehmbaren Unterschied in der Leistung? Fühlen Sie sich ein mehr oder weniger wartbar / lesbar ist als die anderen?

War es hilfreich?

Lösung

Mit dem zweiten Beispiel, das Sie ganz klar sagen, dass beide Bedingungen gegenseitig ausschließen.
Mit dem ersten, ist es nicht so klar, und im (unwahrscheinlichen) Fall, dass eine Zuordnung zu input zwischen beiden ifs hinzugefügt wird, würde die Logik verändern.
Angenommen, jemand in der Zukunft fügt input = 0 vor dem zweiten, wenn.
Natürlich ist dies geschehen unwahrscheinlich, aber wenn wir über Wartbarkeit sprechen hier, wenn-sonst klar sagt, dass es sich gegenseitig aus Bedingungen, während eine Gruppe von ifs dies nicht tun, und sie sind nicht so abhängig von ihnen als sind, wenn -else Blöcke.

bearbeiten. Nun, da ich sehe, in diesem speziellen Beispiel der Rückkehr Klausel Kräfte die gegenseitige Exklusivität, aber wieder, wir reden über die Wartbarkeit und Lesbarkeit

Wie auch immer, über die Leistung, wenn diese in Java codiert ist, sollten Sie nicht für die Leistung von ein paar egal, ob Blöcken, wenn es C eingebettet war in einer wirklich langsam Hardware, vielleicht, aber sicher nicht mit Java.

Andere Tipps

Verwenden Sie, was am besten bilden beschreibt Ihre Absicht.

folgt nicht dem einzigen Ausgang Prinzip, wenn die Dinge so einfach sind, obwohl - es macht es nur mehr verwirrend

.
  • Im ersten:

    jemand schließlich, von irgendeinem seltsamen Grund und wenn Sie nicht einige Add-Anweisung fügt suchen, diese Methode unter bestimmten seltsamen Bedingungen scheitern machen, jeder (oder schlimmstenfalls eine einzige Person) wird 4 Stunden verbringen. den Quellcode und Debuggen der Anwendung beobachten, um endlich etwas in der Mitte war gefunden.

  • Die zweite ist auf jeden Fall besser, es nicht nur dieses Szenario verhindert, sondern hilft auch klar Zustand, es das oder das andere nicht mehr.

    Wenn der gesamte Code schreiben wir innerhalb eines if wo 10 Zeilen lang höchstens würde dies nicht Sache wirklich, aber leider das ist nicht der Fall ist, gibt es andere Programmierer, die denken, aus irgendeinem Grund besteht, dass ein, wenn Körper sein sollte> 200 lange Schlangen ... wie auch immer.

  • Ich weiß nicht, wie die dritten, zwingt sie mich für die Rückkehr Variable zu betrachten, und es ist einfacher, das return Schlüsselwort

  • finden

Über Speed-Performance, sind sie (fast) identisch. Mach dir keine Sorgen darüber.

In Ihrem letzten Beispiel, dies nicht tun:

public boolean foo(int input) {
   boolean toBeReturned = false;
   if(input > 10) {
      doStuff();
      toBeReturned = true;
   } else if(input == 0) {
      doOtherStuff();
      toBeReturned = true;
   }

   return toBeReturned;
}

aber (man beachte die Verwendung von Java final ):

public boolean foo(int input) {
   final boolean toBeReturned;    // no init here
   if(input > 10) {
      doStuff();
      toBeReturned = true;
   } else if(input == 0) {
      doOtherStuff();
      toBeReturned = true;
   } else {
      toBeReturned = false;
   }
   return toBeReturned;
}

Damit Sie Ihre Absicht deutlich machen, und dies ist ein Geschenk des Himmels für IDEs unterstützt „Programmierung von Absicht“ (es gibt keine Notwendigkeit, „Kompilierung“, um mögliche Fehler zu sehen, die auch auf einem Teil AST, eine gute IDE kann unvollständig Quelle untersuchen in Echtzeit und ermöglicht Ihnen sofortigen Warnungen).

So sind Sie sicher nicht zu vergessen, Ihren Rückgabewert zu initialisieren. Das ist toll, wenn Sie später entscheiden, dass schließlich Sie einen anderen Zustand benötigen.

Ich tue dies die ganze Zeit und auch um so mehr, da ich begann mit IntelliJ IDEA (vor Version 4 oder so, eine lange Zeit) und das hat mir so viele dumme Ablenkung Fehler gespeichert ...

Einige Leute argumentieren, dass dies zu viel Code ist für einen solchen einfachen Fall aber das fehlt völlig den Punkt: der Punkt ist die Absicht klar zu machen, so dass der Code liest leicht und später leicht erweitert werden kann, ohne aus Versehen zu vergessen zu assign toBeReturned und ohne versehentlich aus einer späteren Klausel zurückzukehren vergessen Sie hinzufügen können.

Wenn andernfalls „Prägnanz“ ist der Name des Spiels, dann würde ich schreiben:

public boolean foo(int a) {
  return a > 10 ? doStuff() : a == 0 ? doOtherStuff() : false; 
}

Wo beide doStuff und doOtherStuff würde return true.

semantisch - nein. Performance-weise hängt dies von Compiler, das heißt, ob es vor Ort kann, dass beide Bedingungen nicht auf einmal wahr sein können. Ich würde Standard-Sun-Compiler kann wetten. Ob einzelnes Austrittsprinzip zu verwenden, hängt von Geschmack. Ich hasse es, persönlich.

Version # 1 und # 2 kann schneller sein als # 3, aber ich nehme an der Leistungsunterschied ist minimal. Ich würde lieber Fokus auf Lesbarkeit .

Ich persönlich würde nie Version # 2 verwenden. Zwischen # 1 und # 3, würde ich die ein, dass die Renditen der meisten lesbaren Code für den betreffenden Fall wählen. Ich weiß nicht, wie viele Ausstiegspunkte in meinen Methoden, weil sie den Code schwer zu analysieren macht. Es gibt jedoch Fälle, in denen der Fluss klarer wird, wenn wir sofort für einige Sonderfälle verlassen, und fahren Sie mit den wichtigsten Fällen.

von diesem Fall denken, wenn die beiden Beispiele nicht ähnlich sein:

    public boolean foo(int input) {
        if (input > 10) {
            // doStuff();
            return true;
        }
        System.out.println("do some other intermediary stuff");
        if (input == 0) {
            // doOtherStuff();
            return true;
        }

        return false;
    }

vs.

    public boolean foo(int input) {
        if (input > 10) {
            // doStuff();
            return true;
        } 
        //System.out.println("doing some intermediary stuff... doesn't work");
        else if (input == 0) {
            // doOtherStuff();
            return true;
        } else {
            return false;
        }
        return false;
    }

Der erste Ansatz ist wahrscheinlich flexibler , aber beide Formeln haben ihre Verwendung in anderen Umständen.

In Bezug auf Leistung, ich glaube, die Unterschiede zu klein sind, in Betracht gezogen werden, für jede reguläre Java-Anwendung, codiert durch vernünftige Programmierer:)

.

In Ihrem Fall, wenn der zweite wäre nur, wenn die erste aufgerufen, wenn gescheitert, so ist es hier weniger wichtig, aber wenn Sie Ihre erste, wenn etwas tat und kam nicht zurück, die zweite, wenn (die dann immer falsch wäre) würde noch sein getestet, wenn es in einem else-if ist.

Mit anderen Worten, es gibt Fälle, in denen der Unterschied zwischen if-else-if und if-wenn Angelegenheiten, aber das ist nicht einer von ihnen.

Beispiel: das Probieren und dann versuchen, nach dem anderen zu entfernen. Sie erhalten zwei verschiedene Ausgänge:

int someNumber = 1;
if(someNumber < 5)
{
    someNumber += 5;
    Console.WriteLine("First call.");
}
else if(someNumber >= 5)
{
    Console.WriteLine("Second call.");
}

Zwischen dem ersten und dem zweiten Schnipsel, gibt es wirklich keinen Unterschied. Doch der dritte Schnipsel ist ziemlich ineffizient. Weil Sie die Kontrolle über das Programm an den Anrufer bis zur letzten Zeile des Codes in das Verfahren zurück warten, Abfall Sie Rechenleistung / Speicher, während die ersten beiden Codeschnipsel Steuerung sobald zurück, wie es bestimmt eine der Bedingungen wahr zu sein.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top