En supposant que j'ai ce pseudo-code:

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

executeThisFunctionInAnyCase();

Les fonctions executeStepXdoivent être exécutées si et seulement si la précédente réussit. Dans tous les cas, la executeThisFunctionInAnyCasefonction doit être appelée à la fin. Je suis un débutant en programmation, donc désolé pour la question très basique: existe-t-il un moyen (en C / C ++ par exemple) d'éviter que cette longue ifchaîne produise ce genre de "pyramide de code", au détriment de la lisibilité du code ?

Je sais que si nous pouvions ignorer l' executeThisFunctionInAnyCaseappel de fonction, le code pourrait être simplifié comme suit:

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

Mais la contrainte est l' executeThisFunctionInAnyCaseappel de fonction. La breakdéclaration pourrait-elle être utilisée d'une manière ou d'une autre?

Vous pouvez utiliser un &&(logique ET):

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

cela répondra à vos deux exigences:

• executeStep<X>()ne doit évaluer que si le précédent a réussi (c'est ce qu'on appelle l' évaluation des courts-circuits )
• executeThisFunctionInAnyCase() sera exécuté dans tous les cas

Utilisez simplement une fonction supplémentaire pour faire fonctionner votre deuxième version:

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

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

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

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

L'utilisation d'if profondément imbriqués (votre première variante) ou le désir de rompre avec "une partie d'une fonction" signifie généralement que vous avez besoin d'une fonction supplémentaire.

Les programmeurs C de la vieille école utilisent gotodans ce cas. C'est le seul usage gotoqui est réellement encouragé par le guide de style Linux, il s'appelle l'exit de la fonction centralisée:

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;
}

Certaines personnes contournent l'utilisation gotoen enveloppant le corps dans une boucle et en la rompant, mais les deux approches font effectivement la même chose. L' gotoapproche est meilleure si vous avez besoin d'un autre nettoyage uniquement si elle executeStepA()a réussi:

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;
}

Avec l'approche en boucle, vous vous retrouveriez avec deux niveaux de boucles dans ce cas.

Il s'agit d'une situation courante et il existe de nombreuses façons courantes de la gérer. Voici ma tentative de réponse canonique. Veuillez commenter si j'ai raté quelque chose et je garderai ce post à jour.

Ceci est une flèche

Ce que vous discutez est connu sous le nom d' anti-modèle de flèche . Il s'agit d'une flèche car la chaîne d'if imbriqués forme des blocs de code qui se développent de plus en plus à droite puis de nouveau à gauche, formant une flèche visuelle qui "pointe" vers le côté droit du volet de l'éditeur de code.

Aplatissez la flèche avec la garde

Nous discutons ici de quelques moyens courants d'éviter la flèche . La méthode la plus courante consiste à utiliser un modèle de garde , dans lequel le code gère d'abord les flux d'exception, puis gère le flux de base, par exemple au lieu de

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

... vous utiliseriez ....

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

Lorsqu'il y a une longue série de gardes, cela aplatit considérablement le code car toutes les gardes apparaissent complètement à gauche et vos ifs ne sont pas imbriqués. De plus, vous associez visuellement la condition logique à son erreur associée, ce qui permet de savoir plus facilement ce qui se passe:

La Flèche:

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;
}

Garde:

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;
} 

Ceci est objectivement et quantifiablement plus facile à lire car

1. Les caractères {et} pour un bloc logique donné sont plus proches les uns des autres
2. La quantité de contexte mental nécessaire pour comprendre une ligne particulière est plus petite
3. L'intégralité de la logique associée à une condition if est plus susceptible d'être sur une seule page
4. La nécessité pour le codeur de faire défiler la page / l'œil est considérablement réduite

Comment ajouter du code commun à la fin

Le problème avec le modèle de garde est qu'il repose sur ce qu'on appelle le «retour opportuniste» ou la «sortie opportuniste». En d'autres termes, cela rompt le modèle selon lequel chaque fonction doit avoir exactement un point de sortie. Il s'agit d'un problème pour deux raisons:

1. Cela frotte certaines personnes dans le mauvais sens, par exemple les personnes qui ont appris à coder sur Pascal ont appris qu'une fonction = un point de sortie.
2. Il ne fournit pas de section de code qui s'exécute à la sortie, quel que soit le sujet traité .

Ci-dessous, j'ai fourni quelques options pour contourner cette limitation soit en utilisant les fonctionnalités du langage, soit en évitant complètement le problème.

Option 1. Vous ne pouvez pas faire cela: utilisez finally

Malheureusement, en tant que développeur c ++, vous ne pouvez pas faire cela. Mais c'est la réponse numéro un pour les langues qui contiennent un mot-clé finally, car c'est exactement à cela qu'il sert.

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

Option 2. Évitez le problème: restructurez vos fonctions

Vous pouvez éviter le problème en divisant le code en deux fonctions. Cette solution a l'avantage de fonctionner pour n'importe quelle langue, et en outre, elle peut réduire la complexité cyclomatique , qui est un moyen éprouvé de réduire votre taux de défauts, et améliore la spécificité de tous les tests unitaires automatisés.

Voici un exemple:

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

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

Option 3. Astuce linguistique: utilisez une fausse boucle

Une autre astuce que je vois consiste à utiliser while (true) et break, comme indiqué dans les autres réponses.

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

Bien que cela soit moins «honnête» que l'utilisation goto, il est moins susceptible d'être gâché lors de la refactorisation, car il marque clairement les limites de la portée logique. Un codeur naïf qui coupe et colle vos étiquettes ou vos gotorelevés peut causer de gros problèmes! (Et franchement, le modèle est si commun maintenant je pense qu'il communique clairement l'intention, et n'est donc pas du tout "malhonnête").

Il existe d'autres variantes de cette option. Par exemple, on pourrait utiliser à la switchplace de while. Toute construction de langage avec un breakmot clé fonctionnerait probablement.

Option 4. Tirez parti du cycle de vie des objets

Une autre approche exploite le cycle de vie des objets. Utilisez un objet contextuel pour transporter vos paramètres (quelque chose que notre exemple naïf manque étrangement) et éliminez-le lorsque vous avez terminé.

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
}

Remarque: assurez-vous de bien comprendre le cycle de vie de l'objet de la langue de votre choix. Vous avez besoin d'une sorte de ramasse-miettes déterministe pour que cela fonctionne, c'est-à-dire que vous devez savoir quand le destructeur sera appelé. Dans certaines langues, vous devrez utiliser Disposeun destructeur.

Option 4.1. Tirer parti du cycle de vie de l'objet (modèle wrapper)

Si vous allez utiliser une approche orientée objet, autant le faire correctement. Cette option utilise une classe pour «encapsuler» les ressources qui nécessitent un nettoyage, ainsi que ses autres opérations.

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

Encore une fois, assurez-vous de bien comprendre le cycle de vie de votre objet.

Option 5. Astuce linguistique: utiliser l'évaluation de court-circuit

Une autre technique consiste à profiter de l' évaluation des courts-circuits .

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

Cette solution tire parti du fonctionnement de l'opérateur &&. Lorsque le côté gauche de && est évalué à faux, le côté droit n'est jamais évalué.

Cette astuce est plus utile lorsque du code compact est requis et lorsque le code ne risque pas de voir beaucoup de maintenance, par exemple, vous implémentez un algorithme bien connu. Pour un codage plus général, la structure de ce code est trop fragile; même une modification mineure de la logique pourrait déclencher une réécriture totale.

Fais juste

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

C'est si simple.

En raison de trois modifications auxquelles chacune a fondamentalement changé la question (quatre si l'on compte la révision jusqu'à la version 1), j'inclus l'exemple de code auquel je réponds:

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

executeThisFunctionInAnyCase();

Il existe en fait un moyen de différer les actions en C ++: en utilisant le destructeur d'un objet.

En supposant que vous avez accès à 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

Et puis en utilisant cet utilitaire:

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

    // ...

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

    // ...

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

    // ...

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

    // ...

    return 4;
} // foo

Il y a une belle technique qui n'a pas besoin d'une fonction wrapper supplémentaire avec les instructions de retour (la méthode prescrite par Itjax). Il utilise une while(0)pseudo-boucle do . Le while (0)garantit qu'il ne s'agit en fait pas d'une boucle mais qu'il n'est exécuté qu'une seule fois. Cependant, la syntaxe de boucle permet l'utilisation de l'instruction break.

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

Vous pouvez également faire ceci:

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 cette façon, vous avez une taille de croissance linéaire minimale, +1 ligne par appel, et il est facilement maintenable.

EDIT : (Merci @Unda) Pas un grand fan parce que vous perdez la visibilité 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();

Est-ce que cela fonctionnerait? Je pense que c'est équivalent à votre code.

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

En supposant que le code souhaité est tel que je le vois actuellement:

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

Je dirais que l'approche correcte, en ce sens qu'elle est la plus simple à lire et la plus facile à maintenir, aurait moins de niveaux d'indentation, ce qui est (actuellement) l'objectif déclaré de la question.

// 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();

Cela évite tout besoin de gotos, d'exceptions, de whileboucles factices ou d'autres constructions difficiles et continue simplement le travail à portée de main.

La déclaration break pourrait-elle être utilisée d'une manière ou d'une autre?

Ce n'est peut-être pas la meilleure solution, mais vous pouvez mettre vos instructions en do .. while (0)boucle et utiliser des breakinstructions à la place de return.

Vous pouvez mettre toutes les ifconditions, formatées comme vous le souhaitez dans une fonction qui leur est propre, le retour exécute la executeThisFunctionInAnyCase()fonction.

À partir de l'exemple de base de l'OP, les tests et l'exécution des conditions peuvent être séparés en tant que tels;

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

Et puis appelé comme tel;

InitialSteps();
executeThisFunctionInAnyCase();

Si des lambdas C ++ 11 sont disponibles (il n'y avait pas de balise C ++ 11 dans l'OP, mais ils peuvent toujours être une option), alors nous pouvons renoncer à la fonction séparée et envelopper cela dans un 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 vous n'aimez pas gotoet n'aimez pas les do { } while (0);boucles et que vous aimez utiliser C ++, vous pouvez également utiliser un lambda temporaire pour avoir le même effet.

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

executeThisFunctionInAnyCase();

Les chaînes de IF / ELSE dans votre code ne sont pas le problème de langue, mais la conception de votre programme. Si vous êtes en mesure de reformuler ou de réécrire votre programme, je vous suggère de consulter Design Patterns ( http://sourcemaking.com/design_patterns ) pour trouver une meilleure solution.

Habituellement, lorsque vous voyez beaucoup de FI et autres dans votre code, c'est l'occasion d'implémenter le modèle de conception de stratégie ( http://sourcemaking.com/design_patterns/strategy/c-sharp-dot-net ) ou peut-être une combinaison d'autres modèles.

Je suis sûr qu'il existe des alternatives pour écrire une longue liste de if / else, mais je doute qu'ils changeront quoi que ce soit, sauf que la chaîne vous semblera jolie (Cependant, la beauté est dans l'œil du spectateur s'applique toujours au code aussi:-) ) . Vous devriez être préoccupé par des choses comme (dans 6 mois quand j'ai une nouvelle condition et que je ne me souviens de rien de ce code, pourrai-je l'ajouter facilement? Ou si la chaîne change, à quelle vitesse et sans erreur vais-je le mettre en œuvre)

Vous faites juste ça ..

coverConditions();
executeThisFunctionInAnyCase();

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

99 fois sur 100, c'est la seule façon de le faire.

N'essayez jamais, jamais, jamais de faire quelque chose de "délicat" dans le code informatique.

Au fait, je suis presque sûr que ce qui suit est la solution réelle que vous aviez en tête ...

L' instruction continue est essentielle dans la programmation algorithmique. (Autant que, l'instruction goto est critique dans la programmation algorithmique.)

Dans de nombreux langages de programmation, vous pouvez le faire:

-(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");
    }

(Remarquez tout d'abord: les blocs nus comme cet exemple sont une partie critique et importante de l'écriture d'un beau code, en particulier si vous avez affaire à une programmation "algorithmique".)

Encore une fois, c'est exactement ce que vous aviez dans votre tête, non? Et c'est la belle façon de l'écrire, donc vous avez un bon instinct.

Cependant, tragiquement, dans la version actuelle de objective-c (Mis à part - je ne sais pas pour Swift, désolé), il existe une fonctionnalité risible qui vérifie si le bloc englobant est une boucle.

Voici comment contourner cela ...

-(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");
    }

Alors n'oubliez pas que ..

faire {} while (false);

signifie simplement "faire ce bloc une fois".

c'est-à-dire qu'il n'y a absolument aucune différence entre écrire do{}while(false);et simplement écrire {}.

Cela fonctionne maintenant parfaitement comme vous le vouliez ... voici la sortie ...

Il est donc possible que vous voyiez l'algorithme dans votre tête. Vous devriez toujours essayer d'écrire ce que vous avez en tête. (Surtout si vous n'êtes pas sobre, car c'est à ce moment que la jolie sort! :))

Dans les projets "algorithmiques" où cela se produit souvent, dans l'objectif-c, nous avons toujours une macro comme ...

#define RUNONCE while(false)

... alors vous pouvez le faire ...

-(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");
    }

Il y a deux points:

a, même s'il est stupide que objective-c vérifie le type de bloc dans lequel se trouve une instruction continue, il est troublant de "combattre cela". C'est donc une décision difficile.

b, il y a la question si vous indentez, dans l'exemple, ce bloc? Je perds le sommeil sur des questions comme ça, donc je ne peux pas vous conseiller.

J'espère que ça aide.

Demandez à vos fonctions d'exécution de lever une exception si elles échouent au lieu de renvoyer false. Ensuite, votre code d'appel pourrait ressembler à ceci:

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

Bien sûr, je suppose que dans votre exemple d'origine, l'étape d'exécution ne retournerait que faux en cas d'erreur survenant à l'intérieur de l'étape?

Beaucoup de bonnes réponses déjà, mais la plupart d'entre elles semblent faire des compromis sur une partie (certes très peu) de la flexibilité. Une approche courante qui ne nécessite pas ce compromis consiste à ajouter une variable d' état / continue . Le prix est, bien sûr, une valeur supplémentaire pour suivre:

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 question est balisée à la fois C et C ++), si vous ne pouvez pas modifier les fonctions pour utiliser des exceptions, vous pouvez toujours utiliser le mécanisme d'exception si vous écrivez une petite fonction d'aide comme

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

Ensuite, votre code pourrait se lire comme suit:

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

executeThisFunctionInAnyCase();

Si vous êtes dans une syntaxe sophistiquée, vous pouvez le faire fonctionner via un cast explicite:

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

Ensuite, vous pouvez écrire votre code comme

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

executeThisFunctionInAnyCase();

Si votre code est aussi simple que votre exemple et que votre langue prend en charge les évaluations de court-circuit, vous pouvez essayer ceci:

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

Si vous passez des arguments à vos fonctions et récupérez d'autres résultats afin que votre code ne puisse pas être écrit de la manière précédente, la plupart des autres réponses seraient mieux adaptées au problème.

Pour C ++ 11 et au-delà, une bonne approche pourrait être d'implémenter un système de sortie de portée similaire au mécanisme de portée (sortie) de D.

Une façon possible de l'implémenter est d'utiliser des lambdas C ++ 11 et des macros d'assistance:

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 })

Cela vous permettra de revenir tôt à partir de la fonction et de vous assurer que le code de nettoyage que vous définissez est toujours exécuté à la sortie de la portée:

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

if (!executeStepA())
    return;

if (!executeStepB())
    return;

if (!executeStepC())
    return;

Les macros ne sont vraiment que de la décoration. MakeScopeExit()peut être utilisé directement.

Pourquoi personne ne donne la solution la plus simple? :RÉ

Si toutes vos fonctions ont la même signature, vous pouvez le faire de cette façon (pour le langage C):

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

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

    if (!condition) {
        break;
    }
}

executeThisFunctionInAnyCase();

Pour une solution C ++ propre, vous devez créer une classe d'interface qui contient une méthode d' exécution et encapsule vos étapes dans des objets.
Ensuite, la solution ci-dessus ressemblera à ceci:

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

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

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

executeThisFunctionInAnyCase();

En supposant que vous n'avez pas besoin de variables de condition individuelles, inverser les tests et utiliser le else-falthrough comme chemin "ok" vous permettrait d'obtenir un ensemble plus vertical d'instructions 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();

L'omission de la variable échouée rend le code un peu trop obscur IMO.

Déclarer les variables à l'intérieur est très bien, ne vous inquiétez pas de = 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();

C'est obscur, mais compact:

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

runThisFunctionInAnyCase();

Cela ressemble à une machine à états, ce qui est pratique car vous pouvez facilement l'implémenter avec un modèle d'état .

En Java, cela ressemblerait à ceci:

interface StepState{
public StepState performStep();
}

Une implémentation fonctionnerait comme suit:

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

Etc. Ensuite, vous pouvez remplacer la grande condition if par:

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

Comme Rommik l'a mentionné, vous pouvez appliquer un modèle de conception pour cela, mais j'utiliserais le modèle Décorateur plutôt que la stratégie puisque vous souhaitez enchaîner les appels. Si le code est simple, j'irais avec l'une des réponses bien structurées pour empêcher l'imbrication. Cependant, s'il est complexe ou nécessite un chaînage dynamique, le motif Décorateur est un bon choix. Voici un diagramme de classe yUML :

Voici un exemple de programme 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;
    }
}

Le meilleur livre à lire sur les modèles de conception, à mon humble avis, est Head First Design Patterns .

Plusieurs réponses ont fait allusion à un modèle que j'ai vu et utilisé plusieurs fois, en particulier dans la programmation réseau. Dans les piles de réseau, il y a souvent une longue séquence de demandes, dont chacune peut échouer et arrêter le processus.

Le modèle commun était d'utiliser do { } while (false);

J'ai utilisé une macro pour le while(false)faire do { } once;Le motif commun était:

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

Ce modèle était relativement facile à lire, et permettait d'utiliser des objets qui seraient correctement détruits et évitait également les retours multiples, ce qui rendait le pas et le débogage un peu plus faciles.

Pour améliorer la réponse de Mathieu C ++ 11 et éviter les coûts d'exécution engendrés par l'utilisation de std::function, je suggère d'utiliser les éléments suivants

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));
}

Cette classe de modèle simple acceptera n'importe quel foncteur qui peut être appelé sans aucun paramètre, et cela sans aucune allocation de mémoire dynamique et se conforme donc mieux à l'objectif d'abstraction de C ++ sans surcharge inutile. Le modèle de fonction supplémentaire est là pour simplifier l'utilisation par déduction de paramètres de modèle (qui n'est pas disponible pour les paramètres de modèle de classe)

Exemple d'utilisation:

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

Tout comme la réponse de Mathieu, cette solution est totalement sûre et executeThisFunctionInAnyCasesera appelée dans tous les cas. Si eux- executeThisFunctionInAnyCasemêmes lancent, les destructeurs sont marqués implicitement noexceptet par conséquent, un appel à std::terminateserait émis au lieu de provoquer une exception lors du déroulement de la pile.

Il semble que vous souhaitiez passer tous vos appels à partir d'un seul bloc. Comme d'autres l'ont proposé, vous devez utiliser soit une whileboucle et quitter en utilisant breaksoit une nouvelle fonction avec laquelle vous pouvez quitter return(peut être plus propre).

Personnellement goto, je bannis , même pour la sortie de fonction. Ils sont plus difficiles à repérer lors du débogage.

Une alternative élégante qui devrait fonctionner pour votre flux de travail consiste à créer un tableau de fonctions et à itérer sur celui-ci.

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();

Parce que vous avez également [... un bloc de code ...] entre les exécutions, je suppose que vous avez une allocation de mémoire ou des initialisations d'objet. De cette façon, vous devez vous soucier de nettoyer tout ce que vous avez déjà initialisé à la sortie, et également le nettoyer si vous rencontrez un problème et que l'une des fonctions retourne faux.

Dans ce cas, le mieux que j'ai eu dans mon expérience (quand je travaillais avec CryptoAPI) était de créer de petites classes, dans le constructeur vous initialisez vos données, dans le destructeur vous les désinitialisez. Chaque classe de fonction suivante doit être enfant de la classe de fonction précédente. Si quelque chose a mal tourné, jetez l'exception.

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;
};

Et puis dans votre code il vous suffit d'appeler:

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();

Je suppose que c'est la meilleure solution si chaque appel de ConditionX initialise quelque chose, alloue de la mémoire, etc. Mieux vaut être sûr que tout sera nettoyé.

une façon intéressante est de travailler avec des exceptions.

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

Si vous écrivez un tel code, vous allez en quelque sorte dans la mauvaise direction. Je ne le verrai pas comme "le problème" d'avoir un tel code, mais d'avoir une "architecture" aussi désordonnée.

Astuce: discutez de ces cas avec un développeur chevronné en qui vous avez confiance ;-)

Une autre approche - do - whileboucle, même si elle a été mentionnée auparavant, il n'y avait aucun exemple qui montrerait à quoi elle ressemble:

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

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

executeThisFunctionInAnyCase();

_{(Eh bien, il y a déjà une réponse avec whileboucle mais la do - whileboucle ne vérifie pas de manière redondante la vérité (au début) mais à la fin xD (cela peut être ignoré, cependant)).}