if-Anweisung - Kurzschlussbewertung vs. Lesbarkeit

Manchmal kann eine ifAnweisung ziemlich kompliziert oder lang sein. Aus Gründen der Lesbarkeit ist es daher besser, komplizierte Aufrufe vor dem zu extrahieren if.

zB das:

if (SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall())
{
    // do stuff
}

das mögen

bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();

if (b1 || b2)
{
    //do stuff
}

(vorausgesetzt, das Beispiel ist nicht so schlecht, es dient nur zur Veranschaulichung. Stellen Sie sich andere Aufrufe mit mehreren Argumenten usw. vor.)

Aber mit dieser Extraktion habe ich die Kurzschlussbewertung (SCE) verloren.

1. Verliere ich wirklich jedes Mal SCE? Gibt es ein Szenario, in dem der Compiler "es optimieren" und dennoch SCE bereitstellen darf?
2. Gibt es Möglichkeiten, die verbesserte Lesbarkeit des zweiten Snippets beizubehalten, ohne SCE zu verlieren?

Eine natürliche Lösung würde so aussehen:

bool b1 = SomeCondition();
bool b2 = b1 || SomeOtherCondition();
bool b3 = b2 || SomeThirdCondition();
// any other condition
bool bn = bn_1 || SomeFinalCondition();

if (bn)
{
  // do stuff
}

Dies hat den Vorteil, dass es leicht zu verstehen ist, auf alle Fälle anwendbar ist und ein Kurzschlussverhalten aufweist.

Dies war meine anfängliche Lösung: Ein gutes Muster in Methodenaufrufen und for-Schleifenkörpern ist das Folgende:

if (!SomeComplicatedFunctionCall())
   return; // or continue

if (!SomeOtherComplicatedFunctionCall())
   return; // or continue

// do stuff

Man erhält die gleichen guten Leistungsvorteile der Kurzschlussbewertung, aber der Code sieht besser lesbar aus.

Ich neige dazu, Bedingungen in mehrere Zeilen aufzuteilen, dh:

if( SomeComplicatedFunctionCall()
 || OtherComplicatedFunctionCall()
  ) {

Selbst wenn Sie mit mehreren Operatoren (&&) arbeiten, müssen Sie nur die Einrückung für jedes Klammerpaar vorantreiben. SCE setzt immer noch ein - es müssen keine Variablen verwendet werden. Das Schreiben von Code auf diese Weise machte es mir schon seit Jahren viel besser lesbar. Komplexeres Beispiel:

if( one()
 ||( two()> 1337
  &&( three()== 'foo'
   || four()
    )
   )
 || five()!= 3.1415
  ) {

Wenn Sie lange Ketten von Bedingungen haben und einige der Kurzschlüsse beibehalten möchten, können Sie temporäre Variablen verwenden, um mehrere Bedingungen zu kombinieren. Wenn Sie Ihr Beispiel nehmen, wäre es möglich, z

bool b = SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
if (b && some_other_expression) { ... }

Wenn Sie einen C ++ 11-fähigen Compiler haben, können Sie Lambda-Ausdrücke verwenden , um Ausdrücke zu Funktionen zu kombinieren, ähnlich wie oben:

auto e = []()
{
    return SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
};

if (e() && some_other_expression) { ... }

1) Ja, Sie haben keine SCE mehr. Sonst hättest du das

bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();

funktioniert auf die eine oder andere Weise, je nachdem, ob es ifspäter eine Aussage gibt. Viel zu komplex.

2) Dies basiert auf Meinungen, aber für einigermaßen komplexe Ausdrücke können Sie Folgendes tun:

if (SomeComplicatedFunctionCall()
    || OtherComplicatedFunctionCall()) {

Wenn es viel zu komplex ist, besteht die offensichtliche Lösung darin, eine Funktion zu erstellen, die den Ausdruck auswertet und aufruft.

Sie können auch verwenden:

bool b = someComplicatedStuff();
b = b || otherComplicatedStuff(); // it has to be: b = b || ...;  b |= ...; is bitwise OR and SCE is not working then 

und SCE wird funktionieren.

Aber es ist nicht viel lesbarer als zum Beispiel:

if (
    someComplicatedStuff()
    ||
    otherComplicatedStuff()
   )

1) Verliere ich wirklich jedes Mal SCE? Darf der Compiler in einem bestimmten Szenario "optimieren" und trotzdem SCE bereitstellen?

Ich denke nicht, dass eine solche Optimierung erlaubt ist; OtherComplicatedFunctionCall()könnte insbesondere einige Nebenwirkungen haben.

2) Was ist die beste Vorgehensweise in einer solchen Situation? Ist es nur möglich (wenn ich SCE möchte), alles, was ich brauche, direkt in mir zu haben, wenn "und es einfach so formatieren, dass es so lesbar wie möglich ist"?

Ich ziehe es vor, es in eine Funktion oder eine Variable mit einem beschreibenden Namen umzugestalten. Dadurch bleiben sowohl die Kurzschlussbewertung als auch die Lesbarkeit erhalten:

bool getSomeResult() {
    return SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall();
}

...

if (getSomeResult())
{
    //do stuff
}

Und wenn wir getSomeResult()basierend auf SomeComplicatedFunctionCall()und implementieren OtherComplicatedFunctionCall(), können wir sie rekursiv zerlegen, wenn sie noch kompliziert sind.

1) Verliere ich wirklich jedes Mal SCE? Darf der Compiler in einem bestimmten Szenario "optimieren" und trotzdem SCE bereitstellen?

Nein, tust du nicht, aber es wird anders angewendet:

if (SomeComplicatedFunctionCall() || OtherComplicatedFunctionCall())
{
    // do stuff
}

Hier wird der Compiler nicht einmal ausgeführt, OtherComplicatedFunctionCall()wenn SomeComplicatedFunctionCall()true zurückgegeben wird.

bool b1 = SomeComplicatedFunctionCall();
bool b2 = OtherComplicatedFunctionCall();

if (b1 || b2)
{
    //do stuff
}

Hierbei können beide Funktionen werden ausgeführt werden, da sie in gespeichert werden müssen , b1und b2. Ff wird b1 == truedann b2nicht ausgewertet (SCE). Wurde OtherComplicatedFunctionCall()aber schon ausgeführt.

Wenn b2es nirgendwo anders verwendet wird, ist der Compiler möglicherweise intelligent genug, um den Funktionsaufruf im if zu integrieren, wenn die Funktion keine beobachtbaren Nebenwirkungen aufweist.

2) Was ist die beste Vorgehensweise in einer solchen Situation? Ist es nur möglich (wenn ich SCE möchte), alles, was ich brauche, direkt in mir zu haben, wenn "und es einfach so formatieren, dass es so lesbar wie möglich ist"?

Kommt darauf an. Haben Sie brauchen OtherComplicatedFunctionCall() wegen der Nebenwirkungen oder die Performance - Einbußen der Funktion auszuführen ist minimal , dann sollten Sie den zweiten Ansatz zur besseren Lesbarkeit verwenden. Andernfalls bleiben Sie beim ersten Ansatz bei SCE.

Eine andere Möglichkeit, die kurzschließt und die Bedingungen an einem Ort hat:

bool (* conditions [])()= {&a, &b, ...}; // list of conditions
bool conditionsHold = true;
for(int i= 0; i < sizeOf(conditions); i ++){
     if (!conditions[i]()){;
         conditionsHold = false;
         break;
     }
}
//conditionsHold is true if all conditions were met, otherwise false

Sie können die Schleife in eine Funktion einfügen und die Funktion eine Liste von Bedingungen akzeptieren lassen und einen booleschen Wert ausgeben.

Sehr seltsam: Sie sprechen von Lesbarkeit, wenn niemand die Verwendung von Kommentaren im Code erwähnt:

if (somecomplicated_function() || // let me explain what this function does
    someother_function())         // this function does something else
...

Darüber hinaus gehe ich meinen Funktionen immer einige Kommentare voraus, über die Funktion selbst, über ihre Eingabe und Ausgabe, und manchmal füge ich ein Beispiel hinzu, wie Sie hier sehen können:

/*---------------------------*/
/*! interpolates between values
* @param[in] X_axis : contains X-values
* @param[in] Y_axis : contains Y-values
* @param[in] value  : X-value, input to the interpolation process
* @return[out]      : the interpolated value
* @example          : interpolate([2,0],[3,2],2.4) -> 0.8
*/
int interpolate(std::vector<int>& X_axis, std::vector<int>& Y_axis, int value)

Offensichtlich kann die für Ihre Kommentare zu verwendende Formatierung von Ihrer Entwicklungsumgebung abhängen (Visual Studio, JavaDoc unter Eclipse, ...).

Ich gehe davon aus, dass Sie mit SCE Folgendes meinen:

bool b1;
b1 = somecomplicated_function(); // let me explain what this function does
bool b2 = false;
if (!b1) {                       // SCE : if first function call is already true,
                                 // no need to spend resources executing second function.
  b2 = someother_function();     // this function does something else
}

if (b1 || b2) {
...
}

Die Lesbarkeit ist erforderlich, wenn Sie in einem Unternehmen arbeiten und Ihr Code von einer anderen Person gelesen wird. Wenn Sie ein Programm für sich selbst schreiben, liegt es an Ihnen, ob Sie die Leistung für verständlichen Code opfern möchten.