Suponiendo que tengo este pseudocódigo:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}

executeThisFunctionInAnyCase();

Las funciones executeStepXdeben ejecutarse si y solo si las anteriores tienen éxito. En cualquier caso, la executeThisFunctionInAnyCasefunción debe llamarse al final. Soy un novato en programación, lo siento por la pregunta muy básica: ¿hay alguna manera (en C / C ++, por ejemplo) para evitar tanto tiempo?if cadena produzca ese tipo de "pirámide de código", a expensas de la legibilidad del código? ?

Sé que si pudiéramos omitir la executeThisFunctionInAnyCasellamada a la función, el código podría simplificarse como:

bool conditionA = executeStepA();
if (!conditionA) return;
bool conditionB = executeStepB();
if (!conditionB) return;
bool conditionC = executeStepC();
if (!conditionC) return;

Pero la restricción es la executeThisFunctionInAnyCasellamada a la función. ¿Podría la breakdeclaración ser utilizada de alguna manera?

Puede usar un &&(lógico Y):

if (executeStepA() && executeStepB() && executeStepC()){
    ...
}
executeThisFunctionInAnyCase();

Esto satisfará sus dos requisitos:

• executeStep<X>()debe evaluar solo si el anterior tuvo éxito (esto se llama evaluación de cortocircuito )
• executeThisFunctionInAnyCase() se ejecutará en cualquier caso

Simplemente use una función adicional para que su segunda versión funcione:

void foo()
{
  bool conditionA = executeStepA();
  if (!conditionA) return;

  bool conditionB = executeStepB();
  if (!conditionB) return;

  bool conditionC = executeStepC();
  if (!conditionC) return;
}

void bar()
{
  foo();
  executeThisFunctionInAnyCase();
}

El uso de ifs profundamente anidados (su primera variante) o el deseo de salir de "parte de una función" generalmente significa que necesita una función adicional.

Los programadores de la vieja escuela C usan gotoen este caso. Es el único uso gotoque en realidad es alentado por la guía de estilo de Linux, se llama la salida de función centralizada:

int foo() {
    int result = /*some error code*/;
    if(!executeStepA()) goto cleanup;
    if(!executeStepB()) goto cleanup;
    if(!executeStepC()) goto cleanup;

    result = 0;
cleanup:
    executeThisFunctionInAnyCase();
    return result;
}

Algunas personas evitan el uso gotoenvolviendo el cuerpo en un bucle y rompiéndolo, pero efectivamente ambos enfoques hacen lo mismo. El gotoenfoque es mejor si necesita alguna otra limpieza solo si executeStepA()fue exitosa:

int foo() {
    int result = /*some error code*/;
    if(!executeStepA()) goto cleanupPart;
    if(!executeStepB()) goto cleanup;
    if(!executeStepC()) goto cleanup;

    result = 0;
cleanup:
    innerCleanup();
cleanupPart:
    executeThisFunctionInAnyCase();
    return result;
}

Con el enfoque de bucle, terminaría con dos niveles de bucles en ese caso.

Esta es una situación común y hay muchas formas comunes de tratarla. Aquí está mi intento de una respuesta canónica. Comenta si me perdí algo y mantendré esta publicación actualizada.

Esta es una flecha

Lo que está discutiendo se conoce como el antipatrón de flecha . Se llama flecha porque la cadena de ifs anidados forma bloques de código que se expanden más y más hacia la derecha y luego hacia la izquierda, formando una flecha visual que "apunta" al lado derecho del panel del editor de código.

Aplana la flecha con la guardia

Aquí se discuten algunas formas comunes de evitar la flecha . El método más común es usar un patrón de protección , en el que el código maneja los flujos de excepción primero y luego maneja el flujo básico, por ejemplo, en lugar de

if (ok)
{
    DoSomething();
}
else
{
    _log.Error("oops");
    return;
}

... usarías ...

if (!ok)
{
    _log.Error("oops");
    return;
} 
DoSomething(); //notice how this is already farther to the left than the example above

Cuando hay una larga serie de guardias, esto aplana el código considerablemente ya que todos los guardias aparecen completamente a la izquierda y sus ifs no están anidados. Además, está visualmente emparejando la condición lógica con su error asociado, lo que hace que sea mucho más fácil saber lo que está sucediendo:

Flecha:

ok = DoSomething1();
if (ok)
{
    ok = DoSomething2();
    if (ok)
    {
        ok = DoSomething3();
        if (!ok)
        {
            _log.Error("oops");  //Tip of the Arrow
            return;
        }
    }
    else
    {
       _log.Error("oops");
       return;
    }
}
else
{
    _log.Error("oops");
    return;
}

Guardia:

ok = DoSomething1();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething2();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething3();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething4();
if (!ok)
{
    _log.Error("oops");
    return;
} 

Esto es objetiva y cuantificablemente más fácil de leer porque

1. Los caracteres {y} para un bloque lógico dado están más juntos
2. La cantidad de contexto mental necesaria para comprender una línea particular es menor
3. La totalidad de la lógica asociada con una condición if es más probable que esté en una página
4. La necesidad de que el codificador desplace la página / pista ocular disminuye considerablemente

Cómo agregar código común al final

El problema con el patrón de guardia es que se basa en lo que se llama "retorno oportunista" o "salida oportunista". En otras palabras, rompe el patrón de que todas y cada una de las funciones deben tener exactamente un punto de salida. Este es un problema por dos razones:

1. A algunas personas les molesta, por ejemplo, las personas que aprendieron a codificar en Pascal han aprendido que una función = un punto de salida.
2. No proporciona una sección de código que se ejecute al salir, pase lo que pase , cuál es el tema en cuestión.

A continuación, proporcioné algunas opciones para solucionar esta limitación mediante el uso de funciones de idioma o evitando el problema por completo.

Opción 1. No puede hacer esto: use finally

Desafortunadamente, como desarrollador de c ++, no puedes hacer esto. Pero esta es la respuesta número uno para los idiomas que contienen finalmente una palabra clave, ya que esto es exactamente para lo que sirve.

try
{
    if (!ok)
    {
        _log.Error("oops");
        return;
    } 
    DoSomething(); //notice how this is already farther to the left than the example above
}
finally
{
    DoSomethingNoMatterWhat();
}

Opción 2. Evita el problema: reestructura tus funciones

Puede evitar el problema dividiendo el código en dos funciones. Esta solución tiene la ventaja de funcionar para cualquier idioma y, además, puede reducir la complejidad ciclomática , que es una forma comprobada de reducir la tasa de defectos y mejora la especificidad de cualquier prueba unitaria automatizada.

Aquí hay un ejemplo:

void OuterFunction()
{
    DoSomethingIfPossible();
    DoSomethingNoMatterWhat();
}

void DoSomethingIfPossible()
{
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    DoSomething();
}

Opción 3. Truco de idioma: usa un bucle falso

Otro truco común que veo es usar while (verdadero) y break, como se muestra en las otras respuestas.

while(true)
{
     if (!ok) break;
     DoSomething();
     break;  //important
}
DoSomethingNoMatterWhat();

Si bien esto es menos "honesto" que el uso goto, es menos propenso a equivocarse al refactorizar, ya que marca claramente los límites del alcance lógico. ¡Un ingenuo programador que corta y pega sus etiquetas o sus gotodeclaraciones puede causar grandes problemas! (Y, francamente, el patrón es tan común ahora que creo que comunica claramente la intención y, por lo tanto, no es "deshonesto" en absoluto).

Hay otras variantes de estas opciones. Por ejemplo, uno podría usar en switchlugar de while. Cualquier construcción de lenguaje con una breakpalabra clave probablemente funcionaría.

Opción 4. Aproveche el ciclo de vida del objeto

Otro enfoque aprovecha el ciclo de vida del objeto. Use un objeto de contexto para transportar sus parámetros (algo de lo que nuestro ingenuo ejemplo carece sospechosamente) y deséchelo cuando haya terminado.

class MyContext
{
   ~MyContext()
   {
        DoSomethingNoMatterWhat();
   }
}

void MainMethod()
{
    MyContext myContext;
    ok = DoSomething(myContext);
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    ok = DoSomethingElse(myContext);
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    ok = DoSomethingMore(myContext);
    if (!ok)
    {
        _log.Error("Oops");
    }

    //DoSomethingNoMatterWhat will be called when myContext goes out of scope
}

Nota: Asegúrese de comprender el ciclo de vida del objeto de su idioma de elección. Necesitas algún tipo de recolección de basura determinista para que esto funcione, es decir, debes saber cuándo se llamará al destructor. En algunos idiomas deberá usar en Disposelugar de un destructor.

Opción 4.1. Aproveche el ciclo de vida del objeto (patrón de envoltura)

Si va a utilizar un enfoque orientado a objetos, puede hacerlo bien. Esta opción utiliza una clase para "ajustar" los recursos que requieren limpieza, así como sus otras operaciones.

class MyWrapper 
{
   bool DoSomething() {...};
   bool DoSomethingElse() {...}


   void ~MyWapper()
   {
        DoSomethingNoMatterWhat();
   }
}

void MainMethod()
{
    bool ok = myWrapper.DoSomething();
    if (!ok)
        _log.Error("Oops");
        return;
    }
    ok = myWrapper.DoSomethingElse();
    if (!ok)
       _log.Error("Oops");
        return;
    }
}
//DoSomethingNoMatterWhat will be called when myWrapper is destroyed

Nuevamente, asegúrese de comprender el ciclo de vida de su objeto.

Opción 5. Truco del lenguaje: usar evaluación de cortocircuito

Otra técnica es aprovechar la evaluación de cortocircuito .

if (DoSomething1() && DoSomething2() && DoSomething3())
{
    DoSomething4();
}
DoSomethingNoMatterWhat();

Esta solución aprovecha la forma en que funciona el operador &&. Cuando el lado izquierdo de && se evalúa como falso, el lado derecho nunca se evalúa.

Este truco es más útil cuando se requiere un código compacto y cuando no es probable que el código vea mucho mantenimiento, por ejemplo, está implementando un algoritmo bien conocido. Para una codificación más general, la estructura de este código es demasiado frágil; Incluso un cambio menor en la lógica podría desencadenar una reescritura total.

Solo haz

if( executeStepA() && executeStepB() && executeStepC() )
{
    // ...
}
executeThisFunctionInAnyCase();

Es así de simple.

Debido a tres ediciones en las que cada una ha cambiado la pregunta de manera fundamental (cuatro si una cuenta la revisión de nuevo a la versión # 1), incluyo el ejemplo de código al que estoy respondiendo:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}

executeThisFunctionInAnyCase();

En realidad, hay una manera de diferir acciones en C ++: haciendo uso del destructor de un objeto.

Suponiendo que tiene acceso a C ++ 11:

class Defer {
public:
    Defer(std::function<void()> f): f_(std::move(f)) {}
    ~Defer() { if (f_) { f_(); } }

    void cancel() { f_ = std::function<void()>(); }

private:
    Defer(Defer const&) = delete;
    Defer& operator=(Defer const&) = delete;

    std::function<void()> f_;
}; // class Defer

Y luego usando esa utilidad:

int foo() {
    Defer const defer{&executeThisFunctionInAnyCase}; // or a lambda

    // ...

    if (!executeA()) { return 1; }

    // ...

    if (!executeB()) { return 2; }

    // ...

    if (!executeC()) { return 3; }

    // ...

    return 4;
} // foo

Hay una buena técnica que no necesita una función de envoltura adicional con las declaraciones de retorno (el método prescrito por Itjax). Hace uso de un while(0)pseudo-loop do . Esto while (0)asegura que en realidad no es un bucle sino que se ejecuta solo una vez. Sin embargo, la sintaxis del bucle permite el uso de la instrucción break.

void foo()
{
  // ...
  do {
      if (!executeStepA())
          break;
      if (!executeStepB())
          break;
      if (!executeStepC())
          break;
  }
  while (0);
  // ...
}

También puedes hacer esto:

bool isOk = true;
std::vector<bool (*)(void)> funcs; //vector of function ptr

funcs.push_back(&executeStepA);
funcs.push_back(&executeStepB);
funcs.push_back(&executeStepC);
//...

//this will stop at the first false return
for (auto it = funcs.begin(); it != funcs.end() && isOk; ++it) 
    isOk = (*it)();
if (isOk)
 //doSomeStuff
executeThisFunctionInAnyCase();

De esta manera, tiene un tamaño de crecimiento lineal mínimo, +1 línea por llamada, y es fácil de mantener.

EDITAR : (Gracias @Unda) No es un gran fan porque pierdes visibilidad IMO:

bool isOk = true;
auto funcs { //using c++11 initializer_list
    &executeStepA,
    &executeStepB,
    &executeStepC
};

for (auto it = funcs.begin(); it != funcs.end() && isOk; ++it) 
    isOk = (*it)();
if (isOk)
 //doSomeStuff
executeThisFunctionInAnyCase();

¿Funcionaría esto? Creo que esto es equivalente a tu código.

bool condition = true; // using only one boolean variable
if (condition) condition = executeStepA();
if (condition) condition = executeStepB();
if (condition) condition = executeStepC();
...
executeThisFunctionInAnyCase();

Asumiendo que el código deseado es como lo veo actualmente:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}    
executeThisFunctionInAnyCase();

Diría que el enfoque correcto, ya que es el más simple de leer y el más fácil de mantener, tendría menos niveles de sangría, que es (actualmente) el propósito declarado de la pregunta.

// Pre-declare the variables for the conditions
bool conditionA = false;
bool conditionB = false;
bool conditionC = false;

// Execute each step only if the pre-conditions are met
conditionA = executeStepA();
if (conditionA)
    conditionB = executeStepB();
if (conditionB)
    conditionC = executeStepC();
if (conditionC) {
    ...
}

// Unconditionally execute the 'cleanup' part.
executeThisFunctionInAnyCase();

Esto evita cualquier necesidad de gotos, excepciones, whilebucles ficticios u otras construcciones difíciles y simplemente continúa con el simple trabajo en cuestión.

¿Podría la declaración de ruptura ser utilizada de alguna manera?

Tal vez no sea la mejor solución, pero puede poner sus declaraciones en un do .. while (0)bucle y usar breakdeclaraciones en lugar de return.

Podrías poner todo el if condiciones, formateadas como lo desee en una función propia, y al regresar ejecute elexecuteThisFunctionInAnyCase() función.

Desde el ejemplo base en el OP, la prueba de condición y la ejecución se pueden dividir como tal;

void InitialSteps()
{
  bool conditionA = executeStepA();
  if (!conditionA)
    return;
  bool conditionB = executeStepB();
  if (!conditionB)
    return;
  bool conditionC = executeStepC();
  if (!conditionC)
    return;
}

Y luego llamado como tal;

InitialSteps();
executeThisFunctionInAnyCase();

Si las lambdas de C ++ 11 están disponibles (no había una etiqueta de C ++ 11 en el OP, pero aún pueden ser una opción), entonces podemos renunciar a la función separada y envolver esto en una lambda.

// Capture by reference (variable access may be required)
auto initialSteps = [&]() {
  // any additional code
  bool conditionA = executeStepA();
  if (!conditionA)
    return;
  // any additional code
  bool conditionB = executeStepB();
  if (!conditionB)
    return;
  // any additional code
  bool conditionC = executeStepC();
  if (!conditionC)
    return;
};

initialSteps();
executeThisFunctionInAnyCase();

Si no le gustan gotoy no le gustan los do { } while (0);bucles y le gusta usar C ++, también puede usar una lambda temporal para tener el mismo efecto.

[&]() { // create a capture all lambda
  if (!executeStepA()) { return; }
  if (!executeStepB()) { return; }
  if (!executeStepC()) { return; }
}(); // and immediately call it

executeThisFunctionInAnyCase();

Las cadenas de IF / ELSE en su código no son el problema del idioma, sino el diseño de su programa. Si puede refactorizar o reescribir su programa, me gustaría sugerir que busque en Patrones de diseño ( http://sourcemaking.com/design_patterns ) para encontrar una mejor solución.

Por lo general, cuando ve muchos IF y otros en su código, es una oportunidad para implementar el Patrón de diseño de estrategia ( http://sourcemaking.com/design_patterns/strategy/c-sharp-dot-net ) o tal vez una combinación de otros patrones.

Estoy seguro de que hay alternativas para escribir una larga lista de if / else, pero dudo que cambien algo, excepto que la cadena se verá bonita para ti (Sin embargo, la belleza está en el ojo del espectador aún se aplica al código también:-) ) . Debería preocuparse por cosas como (en 6 meses cuando tengo una nueva condición y no recuerdo nada sobre este código, ¿podré agregarlo fácilmente? ¿O qué pasa si la cadena cambia, qué tan rápido y sin errores? voy a implementarlo)

Solo haz esto ...

coverConditions();
executeThisFunctionInAnyCase();

function coverConditions()
 {
 bool conditionA = executeStepA();
 if (!conditionA) return;
 bool conditionB = executeStepB();
 if (!conditionB) return;
 bool conditionC = executeStepC();
 if (!conditionC) return;
 }

99 veces de 100, esta es la única forma de hacerlo.

Nunca, nunca, intentes hacer algo "complicado" en el código de la computadora.

Por cierto, estoy bastante seguro de que el siguiente es el solución real que tenía en mente ...

La declaración de continuación es crítica en la programación algorítmica. (De manera similar, la declaración goto es crítica en la programación algorítmica).

En muchos lenguajes de programación puedes hacer esto:

-(void)_testKode
    {
    NSLog(@"code a");
    NSLog(@"code b");
    NSLog(@"code c\n");
    
    int x = 69;
    
    {
    
    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }
    
    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }
    
    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }
    
    }
    
    NSLog(@"code g");
    }

(Tenga en cuenta en primer lugar: los bloques desnudos como ese ejemplo son una parte crítica e importante de escribir código hermoso, particularmente si se trata de programación "algorítmica").

De nuevo, eso es exactamente lo que tenías en la cabeza, ¿verdad? Y esa es la hermosa manera de escribirlo, así que tienes buenos instintos.

Sin embargo, trágicamente, en la versión actual de Objective-C (aparte: no sé sobre Swift, lo siento) hay una característica risible en la que se comprueba si el bloque de cierre es un bucle.

Así es como lo evitas ...

-(void)_testKode
    {
    NSLog(@"code a");
    NSLog(@"code b");
    NSLog(@"code c\n");
    
    int x = 69;
    
    do{
    
    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }
    
    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }
    
    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }
    
    }while(false);
    
    NSLog(@"code g");
    }

Así que no olvides eso ...

hacer {} while (falso);

solo significa "hacer este bloque una vez".

es decir, no hay absolutamente ninguna diferencia entre escribir do{}while(false);y simplemente escribir {}.

Esto ahora funciona perfectamente como quería ... aquí está la salida ...

Entonces, es posible que así sea como veas el algoritmo en tu cabeza. Siempre debes tratar de escribir lo que tienes en la cabeza. (Particularmente si no estás sobrio, ¡porque es cuando sale lo bonito! :))

En proyectos "algorítmicos" donde esto sucede mucho, en el objetivo-c, siempre tenemos una macro como ...

#define RUNONCE while(false)

... entonces puedes hacer esto ...

-(void)_testKode
    {
    NSLog(@"code a");
    int x = 69;
    
    do{
    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }
    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }
    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }
    }RUNONCE
    
    NSLog(@"code g");
    }

Hay dos puntos:

a, aunque es estúpido que el objetivo-c verifique el tipo de bloque en el que se encuentra una declaración de continuación, es preocupante "luchar contra eso". Entonces es una decisión difícil.

b, está la pregunta, ¿debería sangrar, en el ejemplo, ese bloque? Pierdo el sueño por preguntas como esa, así que no puedo aconsejar.

Espero eso ayude.

Haga que sus funciones de ejecución arrojen una excepción si fallan en lugar de devolver false. Entonces su código de llamada podría verse así:

try {
    executeStepA();
    executeStepB();
    executeStepC();
}
catch (...)

Por supuesto, supongo que en su ejemplo original, el paso de ejecución solo devolvería falso en el caso de que ocurra un error dentro del paso.

Ya hay muchas buenas respuestas, pero la mayoría de ellas parecen compensar algunas (ciertamente muy pocas) de la flexibilidad. Un enfoque común que no requiere esta compensación es agregar una variable de estado / continuación . El precio es, por supuesto, un valor adicional para realizar un seguimiento de:

bool ok = true;
bool conditionA = executeStepA();
// ... possibly edit conditionA, or just ok &= executeStepA();
ok &= conditionA;

if (ok) {
    bool conditionB = executeStepB();
    // ... possibly do more stuff
    ok &= conditionB;
}
if (ok) {
    bool conditionC = executeStepC();
    ok &= conditionC;
}
if (ok && additionalCondition) {
    // ...
}

executeThisFunctionInAnyCase();
// can now also:
return ok;

En C ++ (la pregunta está etiquetada con C y C ++), si no puede cambiar las funciones para usar excepciones, aún puede usar el mecanismo de excepción si escribe una pequeña función auxiliar como

struct function_failed {};
void attempt(bool retval)
{
  if (!retval)
    throw function_failed(); // or a more specific exception class
}

Entonces su código podría leer lo siguiente:

try
{
  attempt(executeStepA());
  attempt(executeStepB());
  attempt(executeStepC());
}
catch (function_failed)
{
  // -- this block intentionally left empty --
}

executeThisFunctionInAnyCase();

Si te gusta la sintaxis elegante, puedes hacer que funcione a través de un reparto explícito:

struct function_failed {};
struct attempt
{
  attempt(bool retval)
  {
    if (!retval)
      throw function_failed();
  }
};

Entonces puedes escribir tu código como

try
{
  (attempt) executeStepA();
  (attempt) executeStepB();
  (attempt) executeStepC();
}
catch (function_failed)
{
  // -- this block intentionally left empty --
}

executeThisFunctionInAnyCase();

Si su código es tan simple como su ejemplo y su idioma admite evaluaciones de cortocircuito, puede intentar esto:

StepA() && StepB() && StepC() && StepD();
DoAlways();

Si pasa argumentos a sus funciones y obtiene otros resultados para que su código no se pueda escribir de la manera anterior, muchas de las otras respuestas se adaptarían mejor al problema.

Para C ++ 11 y más allá, un buen enfoque podría ser implementar un sistema de salida de alcance similar al mecanismo de alcance (salida) de D.

Una posible forma de implementarlo es usando C ++ 11 lambdas y algunas macros auxiliares:

template<typename F> struct ScopeExit 
{
    ScopeExit(F f) : fn(f) { }
    ~ScopeExit() 
    { 
         fn();
    }

    F fn;
};

template<typename F> ScopeExit<F> MakeScopeExit(F f) { return ScopeExit<F>(f); };

#define STR_APPEND2_HELPER(x, y) x##y
#define STR_APPEND2(x, y) STR_APPEND2_HELPER(x, y)

#define SCOPE_EXIT(code)\
    auto STR_APPEND2(scope_exit_, __LINE__) = MakeScopeExit([&](){ code })

Esto le permitirá regresar temprano de la función y garantizar que cualquier código de limpieza que defina siempre se ejecute al salir del ámbito:

SCOPE_EXIT(
    delete pointerA;
    delete pointerB;
    close(fileC); );

if (!executeStepA())
    return;

if (!executeStepB())
    return;

if (!executeStepC())
    return;

Las macros son realmente solo decoración. MakeScopeExit()Se puede usar directamente.

¿Por qué nadie da la solución más simple? :RE

Si todas sus funciones tienen la misma firma, puede hacerlo de esta manera (para lenguaje C):

bool (*step[])() = {
    &executeStepA,
    &executeStepB,
    &executeStepC,
    ... 
};

for (int i = 0; i < numberOfSteps; i++) {
    bool condition = step[i]();

    if (!condition) {
        break;
    }
}

executeThisFunctionInAnyCase();

Para una solución limpia de C ++, debe crear una clase de interfaz que contenga un método de ejecución y envuelva sus pasos en objetos.
Entonces, la solución anterior se verá así:

Step *steps[] = {
    stepA,
    stepB,
    stepC,
    ... 
};

for (int i = 0; i < numberOfSteps; i++) {
    Step *step = steps[i];

    if (!step->execute()) {
        break;
    }
}

executeThisFunctionInAnyCase();

Suponiendo que no necesita variables de condición individuales, invirtiendo las pruebas y utilizando el else-falthrough como la ruta "ok" le permitiría obtener un conjunto más vertical de sentencias if / else:

bool failed = false;

// keep going if we don't fail
if (failed = !executeStepA())      {}
else if (failed = !executeStepB()) {}
else if (failed = !executeStepC()) {}
else if (failed = !executeStepD()) {}

runThisFunctionInAnyCase();

La omisión de la variable fallida hace que el código sea demasiado oscuro para la OMI.

Declarar las variables dentro está bien, no te preocupes por = vs ==.

// keep going if we don't fail
if (bool failA = !executeStepA())      {}
else if (bool failB = !executeStepB()) {}
else if (bool failC = !executeStepC()) {}
else if (bool failD = !executeStepD()) {}
else {
     // success !
}

runThisFunctionInAnyCase();

Esto es oscuro, pero compacto:

// keep going if we don't fail
if (!executeStepA())      {}
else if (!executeStepB()) {}
else if (!executeStepC()) {}
else if (!executeStepD()) {}
else { /* success */ }

runThisFunctionInAnyCase();

Esto parece una máquina de estado, lo cual es útil porque puede implementarlo fácilmente con un patrón de estado .

En Java se vería así:

interface StepState{
public StepState performStep();
}

Una implementación funcionaría de la siguiente manera:

class StepA implements StepState{ 
    public StepState performStep()
     {
         performAction();
         if(condition) return new StepB()
         else return null;
     }
}

Y así. Entonces puede sustituir la condición big if con:

Step toDo = new StepA();
while(toDo != null)
      toDo = toDo.performStep();
executeThisFunctionInAnyCase();

Como Rommik mencionó, podría aplicar un patrón de diseño para esto, pero usaría el patrón Decorador en lugar de la Estrategia, ya que desea encadenar llamadas. Si el código es simple, entonces iría con una de las respuestas bien estructuradas para evitar el anidamiento. Sin embargo, si es complejo o requiere un encadenamiento dinámico, entonces el patrón Decorador es una buena opción. Aquí hay un diagrama de clase yUML :

Aquí hay un ejemplo del programa LinqPad C #:

void Main()
{
    IOperation step = new StepC();
    step = new StepB(step);
    step = new StepA(step);
    step.Next();
}

public interface IOperation 
{
    bool Next();
}

public class StepA : IOperation
{
    private IOperation _chain;
    public StepA(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {
        bool localResult = false;
        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to true
        localResult = true;
        Console.WriteLine("Step A success={0}", localResult);

        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

public class StepB : IOperation
{
    private IOperation _chain;
    public StepB(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {   
        bool localResult = false;

        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to false, 
            // to show breaking out of the chain
        localResult = false;
        Console.WriteLine("Step B success={0}", localResult);

        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

public class StepC : IOperation
{
    private IOperation _chain;
    public StepC(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {
        bool localResult = false;
        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to true
        localResult = true;
        Console.WriteLine("Step C success={0}", localResult);
        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

El mejor libro para leer sobre patrones de diseño, en mi humilde opinión, es Head First Design Patterns .

Varias respuestas insinuaron un patrón que vi y usé muchas veces, especialmente en la programación de redes. En las pilas de red a menudo hay una larga secuencia de solicitudes, cualquiera de las cuales puede fallar y detendrá el proceso.

El patrón común era usar do { } while (false);

Usé una macro para while(false)hacerlo. do { } once;El patrón común era:

do
{
    bool conditionA = executeStepA();
    if (! conditionA) break;
    bool conditionB = executeStepB();
    if (! conditionB) break;
    // etc.
} while (false);

Este patrón era relativamente fácil de leer, y permitía el uso de objetos que destruirían adecuadamente y también evitaba múltiples retornos, lo que facilitaba un poco los pasos y la depuración.

Para mejorar la respuesta de C ++ 11 de Mathieu y evitar el costo de tiempo de ejecución incurrido por el uso de std::function, sugeriría usar lo siguiente

template<typename functor>
class deferred final
{
public:
    template<typename functor2>
    explicit deferred(functor2&& f) : f(std::forward<functor2>(f)) {}
    ~deferred() { this->f(); }

private:
    functor f;
};

template<typename functor>
auto defer(functor&& f) -> deferred<typename std::decay<functor>::type>
{
    return deferred<typename std::decay<functor>::type>(std::forward<functor>(f));
}

Esta clase de plantilla simple aceptará cualquier functor que pueda llamarse sin ningún parámetro, y lo hace sin ninguna asignación de memoria dinámica y, por lo tanto, se ajusta mejor al objetivo de abstracción de C ++ sin sobrecarga innecesaria. La plantilla de función adicional está ahí para simplificar el uso mediante la deducción de parámetros de plantilla (que no está disponible para los parámetros de plantilla de clase)

Ejemplo de uso:

auto guard = defer(executeThisFunctionInAnyCase);
bool conditionA = executeStepA();
if (!conditionA) return;
bool conditionB = executeStepB();
if (!conditionB) return;
bool conditionC = executeStepC();
if (!conditionC) return;

Al igual que la respuesta de Mathieu, esta solución es totalmente segura para excepciones y executeThisFunctionInAnyCasese llamará en todos los casos. En caso de que executeThisFunctionInAnyCasese arroje, los destructores se marcan implícitamente noexcepty, por lo tanto std::terminate, se emitirá una llamada a en lugar de provocar una excepción durante el desenrollado de la pila.

Parece que quieres hacer todas tus llamadas desde un solo bloque. Como otros lo han propuesto, debe usar un whilebucle y dejar de usar breako una nueva función que puede dejar conreturn (puede ser más limpia).

Yo personalmente desterro goto , incluso para la función de salida. Son más difíciles de detectar al depurar.

Una alternativa elegante que debería funcionar para su flujo de trabajo es construir una matriz de funciones e iterar sobre esta.

const int STEP_ARRAY_COUNT = 3;
bool (*stepsArray[])() = {
   executeStepA, executeStepB, executeStepC
};

for (int i=0; i<STEP_ARRAY_COUNT; ++i) {
    if (!stepsArray[i]()) {
        break;
    }
}

executeThisFunctionInAnyCase();

Porque también tienes [... bloque de código ...] entre ejecuciones, supongo que tiene asignación de memoria o inicializaciones de objetos. De esta manera, debe preocuparse por limpiar todo lo que ya ha inicializado en la salida, y también limpiarlo si encuentra algún problema y alguna de las funciones devuelve falso.

En este caso, lo mejor que tuve en mi experiencia (cuando trabajé con CryptoAPI) fue crear clases pequeñas, en el constructor inicializas tus datos, en el destructor no los inicializas. Cada clase de función siguiente debe ser hija de la clase de función anterior. Si algo salió mal, lanza una excepción.

class CondA
{
public:
    CondA() { 
        if (!executeStepA()) 
            throw int(1);
        [Initialize data]
    }
    ~CondA() {        
        [Clean data]
    }
    A* _a;
};

class CondB : public CondA
{
public:
    CondB() { 
        if (!executeStepB()) 
            throw int(2);
        [Initialize data]
    }
    ~CondB() {        
        [Clean data]
    }
    B* _b;
};

class CondC : public CondB
{
public:
    CondC() { 
        if (!executeStepC()) 
            throw int(3);
        [Initialize data]
    }
    ~CondC() {        
        [Clean data]
    }
    C* _c;
};

Y luego en su código solo necesita llamar:

shared_ptr<CondC> C(nullptr);
try{
    C = make_shared<CondC>();
}
catch(int& e)
{
    //do something
}
if (C != nullptr)
{
   C->a;//work with
   C->b;//work with
   C->c;//work with
}
executeThisFunctionInAnyCase();

Supongo que es la mejor solución si cada llamada de ConditionX inicializa algo, asigna memoria, etc. Lo mejor es asegurarse de que todo se limpie.

Una forma interesante es trabajar con excepciones.

try
{
    executeStepA();//function throws an exception on error
    ......
}
catch(...)
{
    //some error handling
}
finally
{
    executeThisFunctionInAnyCase();
}

Si escribe dicho código, de alguna manera va en la dirección equivocada. No lo veré como "el problema" tener ese código, sino tener una "arquitectura" tan desordenada.

Consejo: discuta esos casos con un desarrollador experimentado en el que confíe ;-)

Otro enfoque: do - whilebucle, a pesar de que se mencionó antes, no había ningún ejemplo que mostrara cómo se ve:

do
{
    if (!executeStepA()) break;
    if (!executeStepB()) break;
    if (!executeStepC()) break;
    ...

    break; // skip the do-while condition :)
}
while (0);

executeThisFunctionInAnyCase();

_{(Bueno, ya hay una respuesta con el whilebucle, pero el do - whilebucle no verifica de forma redundante si es verdadero (al principio), sino al final xD (sin embargo, esto se puede omitir)).}