Ritorno da una funzione lunga alla prima condizione di errore

Forse sto abusando di schemi di progettazione o qualcosa del genere, ma lo scriverei come

bool func(some_type_t *p1, another_t *p2) {

    return ( descriptive_name_for_a(p1,p2) &&
             descriptive_name_for_b(p1) &&
             etc );
}

bool descriptive_name_for_a(...) {
    return (some_long && expression && \
        (that_deserves | its_own_line));
}

//etc

}

In questo modo le persone non devono leggere i dettagli delle lunghe espressioni se vogliono solo sapere quale funzione fa.

Perché no:

return
     (long expression a)
     && (long expression b)
     && (long expression c)
     && (etc.)

Questo ritornerà non appena trova il primo valore falso, grazie alla pigrizia di &.

Mi piace l'idea di @ Brad riguardo alla suddivisione in funzioni, ma se non potessi userei più ritorni in questo modo. Non ho scritto C in circa 10 anni, quindi questo è un pseudo-codice C # ...

Modifica: per tenere conto dei commenti di @Frits; senza alcun tentativo di applicare la legge di DeMorgan ...

    bool func(T1 t1, T2)
    {            
        if(!(someLong && expression && (thatDeservers | itsOwnLine)))
            return false;
        if(!(another || longExpression && (thatDeservers | itsOwnLine)))
            return false;
        if(!(andSo && on)
            return false;

        return true;
    }

Non sono un C dev, ma di solito lo formatto con indentazioni e line continua ad essere una singola dichiarazione con il valutatore di cortocircuito. Un'ipotesi approssimativa in C potrebbe essere:

bool func(some_type_t *p1, another_t *p2)
{
  return ((some_long && expression && (that_deserves | its_own_line))) && \
         ((another || long_expression && (that_deserves | its_own_line))) && \
         (and_so && on);
}

Per i miei occhi è comunque molto più leggibile.

Se i blocchi fossero davvero intollerabilmente grandi farei dei sotto-blocchi

bool func(some_type_t *p1, another_t *p2)
{
  return ((some_long && \
              expression && \ 
              (that_deserves | its_own_line))) && \
         ((another || long_expression && \ 
              (that_deserves | its_own_line))) && \
         (and_so && on);
}

Ma forse ho passato troppo tempo a guardare le espressioni lambda ...

I certainly don't want to compromise on readability with a huge if that relies on short circuiting.

Eh? Penso che avere un condizionale basato sul cortocircuito sia il più chiaro e leggibile possibile.

In realtà, anche senza "se".

Proprio

return(a < 2 ? b :
       c < 3 ? d :
               e);

come unica linea nella funzione. Sembra quasi una matematica normale.

Avere più istruzioni che sembrano indipendenti l'una dall'altra ma che in realtà non sono affatto indipendenti è illeggibile ai miei occhi (cioè goto condizionali, variabili bool temporanee).

Ma ovviamente è una questione di preferenze personali.

Utilizza questo modulo utilizzando i controlli ridondanti come ottimizzazione:

bool func(some_type_t *p1, another_t *p2) {
    bool a = false, b = false, c = false;

    a = (some_long && expression && \
        (that_deserves | its_own_line));

    b = a && (another || long_expression && \
        (that_deserves | its_own_line));

    c = b && and_so && on;

    return c;
}

Qui ogni espressione è protetta da una precedente, quindi c'è solo un sovraccarico di runtime trascurabile, indipendentemente dalla durata dell'espressione complicata, poiché nessuno di essi viene valutato inutilmente. Molto probabilmente, il compilatore può eliminare completamente il sovraccarico.

Detto questo, preferirei più dichiarazioni di reso, in quanto sono molto più chiare e meno soggette a errori, IMHO. Ad esempio, ti consentono di riordinare facilmente le parti.

Che ne dici di

#define BREAK_ON_FALSE(x) do { if (!(x)) goto leave_function; } while (0)

void your_function() {
    BREAK_ON_FALSE(first && condition && etc);
    BREAK_ON_FALSE(second && condition && etc);

    /* So on ... */
    return true;
leave_function:
    return false;
}