declaración if – evaluación de cortocircuito vs legibilidad

A veces, un if declaración puede ser bastante complicada o larga, por lo que en aras de la legibilidad es mejor extraer llamadas complicadas antes de la if.

por ejemplo, esto:

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

dentro de esto

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

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

(siempre que el ejemplo no sea que malo, es solo para ilustrar… imagina otras llamadas con múltiples argumentos, etc.)

Pero con esta extracción perdí la evaluación de cortocircuito (SCE).

1. ¿Realmente pierdo SCE cada vez? ¿Existe algún escenario en el que el compilador pueda “optimizarlo” y seguir proporcionando SCE?
2. ¿Hay formas de mantener la legibilidad mejorada del segundo fragmento sin perder SCE?

Una solución natural se vería así:

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

if (bn)
{
  // do stuff
}

Esto tiene los beneficios de ser fácil de entender, ser aplicable a todos los casos y tener un comportamiento de cortocircuito.

Esta fue mi solución inicial: Un buen patrón en llamadas a métodos y cuerpos de bucle for es el siguiente:

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

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

// do stuff

Uno obtiene los mismos buenos beneficios de rendimiento de la evaluación de cortocircuitos, pero el código parece más legible.

Tiendo a dividir las condiciones en varias líneas, es decir:

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

Incluso cuando se trata de múltiples operadores (&&), solo necesita avanzar la sangría con cada par de corchetes. SCE todavía se activa, no es necesario usar variables. Escribir código de esta manera lo hizo mucho más legible para mí durante años. Ejemplo más complejo:

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

Si tiene largas cadenas de condiciones y qué hacer para mantener algunos de los cortocircuitos, entonces podría usar variables temporales para combinar múltiples condiciones. Tomando su ejemplo, sería posible hacer, por ejemplo

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

Si tiene un compilador compatible con C ++ 11, podría usar expresiones lambda para combinar expresiones en funciones, similar a la anterior:

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

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

1) Sí, ya no tienes SCE. De lo contrario, tendrías eso

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

funciona de una forma u otra dependiendo si hay un if declaración más tarde. Demasiado complejo.

2) Esto se basa en opiniones, pero para expresiones razonablemente complejas puede hacer:

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

Si es demasiado complejo, la solución obvia es crear una función que evalúe la expresión y llamarla.

También puedes usar:

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

y SCE funcionará.

Pero no es mucho más legible que, por ejemplo:

if (
    someComplicatedStuff()
    ||
    otherComplicatedStuff()
   )

1) ¿Realmente pierdo SCE cada vez? ¿Se permite al compilador algún escenario para “optimizarlo” y aún proporcionar SCE?

No creo que tal optimización esté permitida; especialmente OtherComplicatedFunctionCall() podría tener algunos efectos secundarios.

2) ¿Cuál es la mejor práctica en tal situación? ¿Es la única posibilidad (cuando quiero SCE) tener todo lo que necesito directamente dentro si y “solo formatearlo para que sea lo más legible posible”?

Prefiero refactorizarlo en una función o una variable con un nombre descriptivo; que preservará tanto la evaluación de cortocircuito como la legibilidad:

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

...

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

Y a medida que implementamos getSomeResult() Residencia en SomeComplicatedFunctionCall() y OtherComplicatedFunctionCall()podríamos descomponerlos recursivamente si aún son complicados.

1) ¿Realmente pierdo SCE cada vez? ¿Se permite al compilador algún escenario para “optimizarlo” y aún proporcionar SCE?

No, no lo hace, pero se aplica de manera diferente:

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

Aquí, el compilador ni siquiera se ejecutará OtherComplicatedFunctionCall() si SomeComplicatedFunctionCall() devuelve verdadero.

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

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

Aquí, ambas funciones voluntad correr porque tienen que ser almacenados en b1 y b2. ff b1 == true después b2 no será evaluado (SCE). Pero OtherComplicatedFunctionCall() ya se ha ejecutado.

Si b2 no se usa en ninguna otra parte el compilador puede que sea ​​lo suficientemente inteligente como para alinear la llamada de función dentro del if si la función no tiene efectos secundarios observables.

2) ¿Cuál es la mejor práctica en tal situación? ¿Es la única posibilidad (cuando quiero SCE) tener todo lo que necesito directamente dentro si y “solo formatearlo para que sea lo más legible posible”?

Eso depende. Tú necesitar OtherComplicatedFunctionCall() para ejecutarse debido a los efectos secundarios o el impacto en el rendimiento de la función es mínimo, entonces debe usar el segundo enfoque para mejorar la legibilidad. De lo contrario, adhiérase a SCE a través del primer enfoque.