Quali sono alcuni modi migliori per evitare il do-while (0); hack in C ++?

Quando il flusso di codice è così:

if(check())
{
  ...
  ...
  if(check())
  {
    ...
    ...
    if(check())
    {
      ...
      ...
    }
  }
}

In genere ho visto questo lavoro in giro per evitare il flusso di codice disordinato sopra:

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

Quali sono alcuni modi migliori per evitare questa soluzione alternativa / hacking in modo che diventi un codice di livello superiore (a livello di settore)?

Tutti i suggerimenti che sono fuori dalla scatola sono i benvenuti!

È considerata pratica accettabile isolare queste decisioni in una funzione e usare returns invece dibreak s. Mentre tutti questi controlli corrispondono allo stesso livello di astrazione della funzione, è un approccio abbastanza logico.

Per esempio:

void foo(...)
{
   if (!condition)
   {
      return;
   }
   ...
   if (!other condition)
   {
      return;
   }
   ...
   if (!another condition)
   {
      return;
   }
   ... 
   if (!yet another condition)
   {
      return;
   }
   ...
   // Some unconditional stuff       
}

Ci sono momenti in cui l'utilizzo gotoè in realtà la risposta GIUSTA - almeno per coloro che non sono cresciuti nella convinzione religiosa che "goto non può mai essere la risposta, non importa quale sia la domanda" - e questo è uno di quei casi.

Questo codice utilizza l'hacking di do { ... } while(0);al solo scopo di vestire un gotoas a break. Se hai intenzione di usaregoto , sii aperto a riguardo. Non ha senso rendere il codice più difficile da leggere.

Una situazione particolare è proprio quando hai un sacco di codice con condizioni abbastanza complesse:

void func()
{
   setup of lots of stuff
   ...
   if (condition)
   {
      ... 
      ...
      if (!other condition)
      {
          ...
          if (another condition)
          {
              ... 
              if (yet another condition)
              {
                  ...
                  if (...)
                     ... 
              }
          }
      }
  .... 

  }
  finish up. 
}

Può effettivamente rendere più CHIARO che il codice è corretto non avendo una logica così complessa.

void func()
{
   setup of lots of stuff
   ...
   if (!condition)
   {
      goto finish;
   }
   ... 
   ...
   if (other condition)
   {
      goto finish;
   }
   ...
   if (!another condition)
   {
      goto finish;
   }
   ... 
   if (!yet another condition)
   {
      goto finish;
   }
   ... 
   .... 
   if (...)
         ...    // No need to use goto here. 
 finish:
   finish up. 
}

Modifica: Per chiarire, non sto assolutamente proponendo l'uso gotocome soluzione generale. Ma ci sono casi in cuigoto c'è una soluzione migliore rispetto ad altre soluzioni.

Immagina, ad esempio, che stiamo raccogliendo alcuni dati e che le diverse condizioni da testare siano una sorta di "questa è la fine dei dati raccolti", che dipende da una sorta di marcatori "continua / fine" che variano a seconda di dove sei nel flusso di dati.

Ora, quando abbiamo finito, dobbiamo salvare i dati in un file.

E sì, ci sono spesso altre soluzioni che possono fornire una soluzione ragionevole, ma non sempre.

È possibile utilizzare un semplice modello di continuazione con una boolvariabile:

bool goOn;
if ((goOn = check0())) {
    ...
}
if (goOn && (goOn = check1())) {
    ...
}
if (goOn && (goOn = check2())) {
    ...
}
if (goOn && (goOn = check3())) {
    ...
}

Questa catena di esecuzione si interromperà non appena checkNritorna a false. Non check...()verranno eseguite ulteriori chiamate a causa di cortocircuiti &&dell'operatore. Inoltre, i compilatori di ottimizzazione sono abbastanza intelligente da riconoscere che l'impostazione goOndi falseuna strada a senso unico, e inserire i dispersi goto endper voi. Di conseguenza, l'esecuzione del codice sopra sarebbe identica a quella di un do/ while(0), solo senza un colpo doloroso alla sua leggibilità.

1. Prova a estrarre il codice in una funzione separata (o forse più di una). Quindi tornare dalla funzione se il controllo fallisce.

2. Se è troppo strettamente accoppiato con il codice circostante per farlo, e non riesci a trovare un modo per ridurre l'accoppiamento, guarda il codice dopo questo blocco. Presumibilmente, pulisce alcune risorse utilizzate dalla funzione. Prova a gestire queste risorse usando un oggetto RAII ; quindi sostituisci ogni schivata breakcon return(o throw, se è più appropriato) e lascia che il distruttore dell'oggetto pulisca per te.

3. Se il flusso del programma è (necessariamente) così debole che hai davvero bisogno di un goto, allora usa quello piuttosto che dargli uno strano travestimento.

4. Se hai regole di codifica che ciecamente vietano gotoe davvero non puoi semplificare il flusso del programma, probabilmente dovrai mascherarlo con il tuo dohack.

TLDR : RAII , codice transazionale (impostare risultati o restituire elementi solo quando è già calcolato) ed eccezioni.

Risposta lunga:

In C , la migliore pratica per questo tipo di codice è quella di aggiungere un'etichetta EXIT / CLEANUP / altra nel codice, in cui avviene la pulizia delle risorse locali e viene restituito un codice di errore (se presente). Questa è la migliore pratica perché divide naturalmente il codice in inizializzazione, calcolo, commit e return:

error_code_type c_to_refactor(result_type *r)
{
    error_code_type result = error_ok; //error_code_type/error_ok defd. elsewhere
    some_resource r1, r2; // , ...;
    if(error_ok != (result = computation1(&r1))) // Allocates local resources
        goto cleanup;
    if(error_ok != (result = computation2(&r2))) // Allocates local resources
        goto cleanup;
    // ...

    // Commit code: all operations succeeded
    *r = computed_value_n;
cleanup:
    free_resource1(r1);
    free_resource2(r2);
    return result;
}

In C, nella maggior parte dei basi di codice, il if(error_ok != ...e il gotocodice è di solito nascosto dietro alcune macro di convenienza ( RET(computation_result), ENSURE_SUCCESS(computation_result, return_code), ecc).

C ++ offre strumenti extra rispetto a C :

• La funzionalità del blocco di pulizia può essere implementata come RAII, il che significa che non è più necessario l'intero cleanupblocco e consente al codice client di aggiungere dichiarazioni di restituzione anticipate.

• Lanci ogni volta che non puoi continuare, trasformando tutte le if(error_ok != ...chiamate in diretta.

Codice C ++ equivalente:

result_type cpp_code()
{
    raii_resource1 r1 = computation1();
    raii_resource2 r2 = computation2();
    // ...
    return computed_value_n;
}

Questa è la migliore pratica perché:

• È esplicito (ovvero, mentre la gestione degli errori non è esplicita, il flusso principale dell'algoritmo è)

• È semplice scrivere il codice client

• È minimo

• È semplice

• Non ha costrutti di codice ripetitivi

• Non utilizza macro

• Non usa do { ... } while(0)costrutti strani

• È riutilizzabile con il minimo sforzo (ovvero, se voglio copiare la chiamata in computation2();un'altra funzione, non devo assicurarmi di aggiungere un do { ... } while(0)nel nuovo codice, né #defineuna macro wrapper e un'etichetta di pulizia, né qualunque altra cosa).

Sto aggiungendo una risposta per completezza. Numerose altre risposte hanno sottolineato che il blocco delle condizioni di grandi dimensioni potrebbe essere suddiviso in una funzione separata. Ma, come è stato anche sottolineato più volte, questo approccio separa il codice condizionale dal contesto originale. Questo è uno dei motivi per cui i lambda sono stati aggiunti alla lingua in C ++ 11. L'uso di lambda è stato suggerito da altri ma non è stato fornito alcun campione esplicito. Ne ho inserito uno in questa risposta. Ciò che mi colpisce è che sembra molto simile do { } while(0)all'approccio in molti modi - e forse ciò significa che è ancora gotosotto mentite spoglie ...

earlier operations
...
[&]()->void {

    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
}();
later operations

Certamente non la risposta, ma una risposta (per completezza)

Invece di :

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

Puoi scrivere:

switch (0) {
case 0:
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

Questo è ancora un goto sotto mentite spoglie, ma almeno non è più un ciclo. Ciò significa che non dovrete controllare con molta attenzione che non ci sia alcuno di continuare nascosti da qualche parte nel blocco.

Il costrutto è anche abbastanza semplice da sperare che il compilatore lo ottimizzi via.

Come suggerito da @jamesdlin, puoi persino nasconderlo dietro una macro come

#define BLOC switch(0) case 0:

E usalo come

BLOC {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

Ciò è possibile perché la sintassi del linguaggio C prevede un'istruzione dopo uno switch, non un blocco tra parentesi e puoi inserire un'etichetta case prima di tale istruzione. Fino ad ora non ho visto il punto di permetterlo, ma in questo caso particolare è utile nascondere l'interruttore dietro una bella macro.

Consiglierei un approccio simile alla risposta di Mats meno l'inutile goto. Metti solo la logica condizionale nella funzione. Qualsiasi codice che viene sempre eseguito dovrebbe andare prima o dopo che la funzione è stata invocata nel chiamante:

void main()
{
    //do stuff always
    func();
    //do other stuff always
}

void func()
{
    if (!condition)
        return;
    ...
    if (!other condition)
        return;
    ...
    if (!another condition)
        return;
    ... 
    if (!yet another condition)
        return;
    ...
}

Il flusso di codice stesso è già un odore di codice che sta succedendo molto nella funzione. Se non esiste una soluzione diretta a ciò (la funzione è una funzione di controllo generale), utilizzare RAII in modo da poter tornare invece di saltare a una sezione finale della funzione potrebbe essere migliore.

Se non è necessario introdurre variabili locali durante l'esecuzione, è spesso possibile appiattire questo:

if (check()) {
  doStuff();
}  
if (stillOk()) {
  doMoreStuff();
}
if (amIStillReallyOk()) {
  doEvenMore();
}

// edit 
doThingsAtEndAndReportErrorStatus()

Simile alla risposta di dasblinkenlight, ma evita l'assegnazione all'interno ifche potrebbe essere "riparata" da un revisore del codice:

bool goOn = check0();
if (goOn) {
    ...
    goOn = check1();
}
if (goOn) {
    ...
    goOn = check2();
}
if (goOn) {
    ...
}

...

Uso questo modello quando i risultati di un passaggio devono essere controllati prima del passaggio successivo, che differisce da una situazione in cui tutti i controlli potrebbero essere eseguiti in anticipo con un if( check1() && check2()...modello di tipo grande .

Usa le eccezioni. Il codice apparirà molto più pulito (e sono state create eccezioni esattamente per la gestione degli errori nel flusso di esecuzione di un programma). Per ripulire le risorse (descrittori di file, connessioni al database, ecc.), Leggi l'articolo Perché C ++ non fornisce un costrutto "finalmente"? .

#include <iostream>
#include <stdexcept>   // For exception, runtime_error, out_of_range

int main () {
    try {
        if (!condition)
            throw std::runtime_error("nope.");
        ...
        if (!other condition)
            throw std::runtime_error("nope again.");
        ...
        if (!another condition)
            throw std::runtime_error("told you.");
        ...
        if (!yet another condition)
            throw std::runtime_error("OK, just forget it...");
    }
    catch (std::runtime_error &e) {
        std::cout << e.what() << std::endl;
    }
    catch (...) {
        std::cout << "Caught an unknown exception\n";
    }
    return 0;
}

Per me do{...}while(0)va bene. Se non vuoi vedere ildo{...}while(0) , puoi definire parole chiave alternative per loro.

Esempio:

//--------SomeUtilities.hpp---------
#define BEGIN_TEST do{
#define END_TEST }while(0);

//--------SomeSourceFile.cpp--------
BEGIN_TEST
   if(!condition1) break;
   if(!condition2) break;
   if(!condition3) break;
   if(!condition4) break;
   if(!condition5) break;

   //processing code here

END_TEST

Penso che il compilatore rimuoverà la while(0)condizione non necessaria indo{...}while(0) versione binaria e convertirà le interruzioni in salto incondizionato. Puoi verificarne la versione in linguaggio assembly per essere sicuro.

L'utilizzo gotoproduce anche un codice più pulito ed è semplice con la logica condition-then-jump. Puoi fare quanto segue:

{
   if(!condition1) goto end_blahblah;
   if(!condition2) goto end_blahblah;
   if(!condition3) goto end_blahblah;
   if(!condition4) goto end_blahblah;
   if(!condition5) goto end_blahblah;

   //processing code here

 }end_blah_blah:;  //use appropriate label here to describe...
                   //  ...the whole code inside the block.

Si noti che l'etichetta viene posizionata dopo la chiusura }. Questo è l'evitamento di un possibile problema gotoche consiste nel posizionare accidentalmente un codice in mezzo perché non hai visto l'etichetta. Ora è come do{...}while(0)senza codice condizione.

Per rendere questo codice più pulito e comprensibile, puoi farlo:

//--------SomeUtilities.hpp---------
#define BEGIN_TEST {
#define END_TEST(_test_label_) }_test_label_:;
#define FAILED(_test_label_) goto _test_label_

//--------SomeSourceFile.cpp--------
BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);
   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);
   if(!condition5) FAILED(NormalizeData);

END_TEST(NormalizeData)

Con questo, puoi fare blocchi nidificati e specificare dove vuoi uscire / saltare.

//--------SomeUtilities.hpp---------
#define BEGIN_TEST {
#define END_TEST(_test_label_) }_test_label_:;
#define FAILED(_test_label_) goto _test_label_

//--------SomeSourceFile.cpp--------
BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);

   BEGIN_TEST
      if(!conditionAA) FAILED(DecryptBlah);
      if(!conditionBB) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionCC) FAILED(DecryptBlah);

      // --We can now decrypt and do other stuffs.

   END_TEST(DecryptBlah)

   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);

   // --other code here

   BEGIN_TEST
      if(!conditionA) FAILED(TrimSpaces);
      if(!conditionB) FAILED(TrimSpaces);
      if(!conditionC) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionD) FAILED(TrimSpaces);

      // --We can now trim completely or do other stuffs.

   END_TEST(TrimSpaces)

   // --Other code here...

   if(!condition5) FAILED(NormalizeData);

   //Ok, we got here. We can now process what we need to process.

END_TEST(NormalizeData)

Il codice spaghetti non è colpa di goto, è colpa del programmatore. Puoi ancora produrre il codice spaghetti senza usare goto.

Questo è un problema ben noto e risolto dal punto di vista funzionale della programmazione - forse la monade.

In risposta al commento che ho ricevuto di seguito ho modificato la mia introduzione qui: Puoi trovare tutti i dettagli sull'implementazione delle monadi C ++ in vari luoghi che ti permetteranno di ottenere ciò che suggerisce Rotsor. Ci vuole un po 'per ingannare le monadi, quindi suggerirò qui un rapido meccanismo simile a una monade "povero" per il quale non è necessario sapere altro che boost :: opzionale.

Imposta i tuoi passi di calcolo come segue:

boost::optional<EnabledContext> enabled(boost::optional<Context> context);
boost::optional<EnergisedContext> energised(boost::optional<EnabledContext> context);

Ogni passaggio computazionale può ovviamente fare qualcosa come return boost::nonese l'opzione opzionale che gli è stata fornita è vuota. Quindi per esempio:

struct Context { std::string coordinates_filename; /* ... */ };

struct EnabledContext { int x; int y; int z; /* ... */ };

boost::optional<EnabledContext> enabled(boost::optional<Context> c) {
   if (!c) return boost::none; // this line becomes implicit if going the whole hog with monads
   if (!exists((*c).coordinates_filename)) return boost::none; // return none when any error is encountered.
   EnabledContext ec;
   std::ifstream file_in((*c).coordinates_filename.c_str());
   file_in >> ec.x >> ec.y >> ec.z;
   return boost::optional<EnabledContext>(ec); // All ok. Return non-empty value.
}

Quindi incatenali insieme:

Context context("planet_surface.txt", ...); // Close over all needed bits and pieces

boost::optional<EnergisedContext> result(energised(enabled(context)));
if (result) { // A single level "if" statement
    // do work on *result
} else {
    // error
}

La cosa bella di questo è che puoi scrivere unit test chiaramente definiti per ogni passaggio computazionale. Anche l'invocazione si legge come un semplice inglese (come di solito accade con lo stile funzionale).

Se non ti interessa l'immutabilità ed è più conveniente restituire lo stesso oggetto ogni volta che potresti trovare qualche variazione usando shared_ptr o simili.

Che ne dici di spostare le istruzioni if ​​in una funzione extra che produce un risultato numerico o enumico?

int ConditionCode (void) {
   if (condition1)
      return 1;
   if (condition2)
      return 2;
   ...
   return 0;
}


void MyFunc (void) {
   switch (ConditionCode ()) {
      case 1:
         ...
         break;

      case 2:
         ...
         break;

      ...

      default:
         ...
         break;
   }
}

Qualcosa del genere forse

#define EVER ;;

for(EVER)
{
    if(!check()) break;
}

o utilizzare le eccezioni

try
{
    for(;;)
        if(!check()) throw 1;
}
catch()
{
}

Usando le eccezioni puoi anche passare i dati.

Non mi piace particolarmente usare breakoreturn in tal caso. Dato che normalmente quando ci troviamo di fronte a una situazione del genere, di solito è un metodo relativamente lungo.

Se abbiamo più punti di uscita, ciò può causare difficoltà quando vogliamo sapere cosa causerà l'esecuzione di una certa logica: normalmente continuiamo a salire su blocchi che racchiudono quel pezzo di logica, e i criteri di quei blocchi che racchiudono ci dicono il situazione:

Per esempio,

if (conditionA) {
    ....
    if (conditionB) {
        ....
        if (conditionC) {
            myLogic();
        }
    }
}

Osservando i blocchi racchiusi, è facile scoprire che ciò myLogic()accade solo quando conditionA and conditionB and conditionCè vero.

Diventa molto meno visibile quando ci sono ritorni precoci:

if (conditionA) {
    ....
    if (!conditionB) {
        return;
    }
    if (!conditionD) {
        return;
    }
    if (conditionC) {
        myLogic();
    }
}

Non possiamo più risalire da myLogic(), guardando il blocco che racchiude per capire la condizione.

Ci sono diverse soluzioni alternative che ho usato. Eccone uno:

if (conditionA) {
    isA = true;
    ....
}

if (isA && conditionB) {
    isB = true;
    ...
}

if (isB && conditionC) {
    isC = true;
    myLogic();
}

(Ovviamente è gradito usare la stessa variabile per sostituire tutto isA isB isC .)

Tale approccio fornirà almeno al lettore di codice, che myLogic()viene eseguito quando isB && conditionC. Al lettore viene dato un suggerimento che deve cercare ulteriormente ciò che farà sì che isB sia vero.

typedef bool (*Checker)();

Checker * checkers[]={
 &checker0,&checker1,.....，&checkerN,NULL
};

bool checker1(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

bool checker2(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

......

void doCheck(){
  Checker ** checker = checkers;
  while( *checker && (*checker)())
    checker++;
}

Che ne dici di quello?

Un altro modello utile se sono necessari diversi passaggi di pulizia a seconda di dove si trova l'errore:

    private ResultCode DoEverything()
    {
        ResultCode processResult = ResultCode.FAILURE;
        if (DoStep1() != ResultCode.SUCCESSFUL)
        {
            Step1FailureCleanup();
        }
        else if (DoStep2() != ResultCode.SUCCESSFUL)
        {
            Step2FailureCleanup();
            processResult = ResultCode.SPECIFIC_FAILURE;
        }
        else if (DoStep3() != ResultCode.SUCCESSFUL)
        {
            Step3FailureCleanup();
        }
        ...
        else
        {
            processResult = ResultCode.SUCCESSFUL;
        }
        return processResult;
    }

Non sono un programmatore C ++ , quindi non scriverò alcun codice qui, ma finora nessuno ha menzionato una soluzione orientata agli oggetti. Quindi ecco la mia ipotesi su questo:

Avere un'interfaccia generica che fornisce un metodo per valutare una singola condizione. Ora puoi utilizzare un elenco di implementazioni di tali condizioni nel tuo oggetto contenente il metodo in questione. Si scorre l'elenco e si valuta ogni condizione, possibilmente esplodendo in anticipo se si fallisce.

La cosa buona è che tale design si attiene molto bene al principio aperto / chiuso , perché è possibile aggiungere facilmente nuove condizioni durante l'inizializzazione dell'oggetto contenente il metodo in questione. È anche possibile aggiungere un secondo metodo all'interfaccia con il metodo per la valutazione delle condizioni restituendo una descrizione della condizione. Questo può essere usato per sistemi di auto-documentazione.

Il rovescio della medaglia, tuttavia, è che c'è un leggero sovraccarico in più a causa dell'uso di più oggetti e dell'iterazione sull'elenco.

Questo è il modo in cui lo faccio.

void func() {
  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...
}

Innanzitutto, un breve esempio per mostrare perché gotonon è una buona soluzione per C ++:

struct Bar {
    Bar();
};

extern bool check();

void foo()
{
    if (!check())
       goto out;

    Bar x;

    out:
}

Prova a compilarlo in un file oggetto e guarda cosa succede. Quindi prova l'equivalente do+ break+while(0) .

Era un lato. Segue il punto principale.

Quei piccoli pezzi di codice spesso richiedono un qualche tipo di pulizia se l'intera funzione fallisce. Quelle pulizie di solito vogliono avvenire nell'ordine opposto rispetto ai pezzi stessi, mentre "srotoli" il calcolo parzialmente finito.

Un'opzione per ottenere queste semantiche è RAII ; vedi la risposta di @utnapistim. C ++ garantisce che i distruttori automatici funzionino nell'ordine opposto rispetto ai costruttori, il che fornisce naturalmente un "svolgersi".

Ma ciò richiede molte classi RAII. A volte un'opzione più semplice è solo per usare lo stack:

bool calc1()
{
    if (!check())
        return false;

    // ... Do stuff1 here ...

    if (!calc2()) {
        // ... Undo stuff1 here ...
        return false;
    }

    return true;
}

bool calc2()
{
    if (!check())
        return false;

    // ... Do stuff2 here ...

    if (!calc3()) {
        // ... Undo stuff2 here ...
        return false;
    }

    return true;
}

...e così via. Questo è facile da controllare, poiché mette il codice "annulla" accanto al codice "do". Il controllo semplice è buono. Rende inoltre molto chiaro il flusso di controllo. È un modello utile anche per C.

Può richiedere che le calcfunzioni prendano molti argomenti, ma questo di solito non è un problema se le tue classi / strutture hanno una buona coesione. (Cioè, le cose che appartengono insieme vivono in un singolo oggetto, quindi queste funzioni possono prendere puntatori o riferimenti a un piccolo numero di oggetti e fare ancora molto lavoro utile.)

Se il codice ha un blocco lungo di istruzioni if..else if..else, puoi provare a riscrivere l'intero blocco con l'aiuto di Functorso function pointers. Potrebbe non essere la soluzione giusta sempre, ma abbastanza spesso lo è.

http://www.cprogramming.com/tutorial/functors-function-objects-in-c++.html

Sono sorpreso dal numero di risposte diverse presentate qui. Ma, infine, nel codice che devo modificare (cioè rimuovere questo do-while(0)hack o altro), ho fatto qualcosa di diverso da una qualsiasi delle risposte menzionate qui e sono confuso perché nessuno lo ha pensato. Ecco cosa ho fatto:

Codice iniziale:

do {

    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

finishingUpStuff.

Adesso:

finish(params)
{
  ...
  ...
}

if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...

Quindi, ciò che è stato fatto qui è che le cose di finitura sono state isolate in una funzione e le cose sono diventate improvvisamente così semplici e pulite!

Ho pensato che valesse la pena menzionare questa soluzione, quindi fornirla qui.

Consolidalo in una sola ifistruzione:

if(
    condition
    && other_condition
    && another_condition
    && yet_another_condition
    && ...
) {
        if (final_cond){
            //Do stuff
        } else {
            //Do other stuff
        }
}

Questo è il modello utilizzato in lingue come Java in cui è stata rimossa la parola chiave goto.

Se si utilizza lo stesso gestore degli errori per tutti gli errori e ogni passaggio restituisce un valore booleano che indica l'esito positivo:

if(
    DoSomething() &&
    DoSomethingElse() &&
    DoAThirdThing() )
{
    // do good condition action
}
else
{
    // handle error
}

(Simile alla risposta del tyzoid, ma le condizioni sono le azioni e && impedisce che si verifichino ulteriori azioni dopo il primo fallimento.)

Perché il metodo di segnalazione non ha risposto, è usato da secoli.

//you can use something like this (pseudocode)
long var = 0;
if(condition)  flag a bit in var
if(condition)  flag another bit in var
if(condition)  flag another bit in var
............
if(var == certain number) {
Do the required task
}