È mai accettabile che un condizionale abbia effetti collaterali? [chiuso]

Sto seguendo un corso intermedio sulle strutture di dati come prerequisito per l'ingresso nel programma CS MS in un'università di cui tutti in America hanno sentito parlare. Una riga di codice scritta in classe attirò la mia attenzione:

if (a > 33 | b++ < 54) {...}

Questo non passerebbe una revisione del codice sul mio posto di lavoro. Se hai scritto codice come questo in un'intervista, questo sarebbe uno sciopero significativo contro di te. (Oltre ad essere un condizionale con effetti collaterali, è intelligente a scapito della chiarezza.)

In realtà, non ho mai visto un condizionale con effetti collaterali e anche Google non si presenta molto. Anche un altro studente è rimasto indietro dopo le lezioni per chiederlo, quindi non sono l'unico a pensare che questo sia strano. Ma il professore era piuttosto irremovibile che questo era un codice accettabile e che avrebbe scritto qualcosa del genere al lavoro. (Il suo lavoro in FT è di SWE principale presso un'azienda di cui tutti avete sentito parlare.)

Non riesco a immaginare un mondo in cui questa linea di codice sia mai accettabile, tanto meno desiderabile. Ho sbagliato? Va bene? Che dire del caso più generale: i condizionali con effetti collaterali? Sono mai a posto?

C'è un effetto collaterale semi-condizionale a cui riesco a pensare che va bene:while(iter.MoveNext())

Detto questo, penso che questo rientri principalmente nella categoria " non è mai un grande qualificatore". Mi vengono in mente alcuni rari casi in cui l'ho visto accettabile, ma in generale questo è vile e da evitare.

Inoltre non riesco a pensare a uno scenario in cui quella particolare linea sarebbe accettabile, ma non riesco nemmeno a pensare a uno scenario in cui quella particolare linea sarebbe utile , quindi è difficile immaginare il contesto in cui si trova.

Nel mio mondo, una lettura dalla memoria può essere considerata un effetto collaterale (ad es. IO mappato in memoria).

Ora, considera quanto segue:

    while( ( *memory_mapped_device_status_register & READY_FLAG) == 0) {
       // Wait
    }

E confronta con:

    status = *memory_mapped_device_status_register;
    while( ( status & READY_FLAG) == 0) {
        // Wait
        status = *memory_mapped_device_status_register;
    }

Evitare l'effetto collaterale (la lettura) nella condizione aiuta la leggibilità; o ha semplicemente duplicato il codice e aggiunto disordine?

Non è OK che una condizione abbia effetti collaterali (se ciò rende il codice meno leggibile) ed è anche OK che una condizione abbia effetti collaterali (se ciò rende il codice più leggibile). Il fattore chiave è la "leggibilità". Tutto il resto sono regole create dagli sciocchi nel tentativo sbagliato di migliorare la leggibilità (pur avendo spesso l'effetto opposto).

Come sempre con tali domande, questa è una questione di laurea. Se ci fosse una prova inequivocabile che qualsiasi effetto collaterale all'interno di ifun'espressione portava sempre a un codice peggiore, allora non sarebbe legale creare quelle espressioni. I progettisti linguistici possono essere umani ideosincratici e fallibili, ma non sono così stupidi.

Detto questo, quali sono gli esempi di effetti collaterali giustificati all'interno di un if? Ad esempio, supponiamo che tu sia legalmente tenuto a registrare tutti e tutti gli accessi alla proprietà Pdi un'entità Ea fini di audit. (Immagina di lavorare in un impianto di arricchimento dell'uranio e che ci sono controlli legali molto severi su ciò che il tuo codice è autorizzato a fare e su come dovrebbe farlo.) Quindi chiunque ifcontrolli quella proprietà causerà l'effetto collaterale del registro di controllo in fase di estensione.

Questa è una preoccupazione trasversale piuttosto chiara, non influisce sul tuo ragionamento sullo stato del programma (molto) e puoi implementarlo in modo che sia completamente invisibile e non distratto quando rivedi la linea con if(nascosto via nell'accessorio, o ancora meglio via AOP). Direi che è un caso abbastanza chiaro di un effetto collaterale che non è un problema. Situazioni simili potrebbero essere immaginate quando si desidera solo contare le esecuzioni di rami per scopi di profilazione, ecc.

Più queste circostanze attenuanti scompaiono, più estraneo diventerà il costrutto. Se un particolare tipo di loop (ad esempio if((c = getc()) == 'x') { quit(); }è ben noto e accettato dalla comunità linguistica, allora è un problema molto meno grave rispetto a quando lo inventi spontaneamente, ecc. La tua riga di esempio non è all'altezza di quello standard, ma potrei immaginare molto, molto quelli più orribili che non scriverò nemmeno, sono così orribili.

Sebbene sia un codice davvero puzzolente, ha il vantaggio di essere più semplice (e forse più veloce se non si dispone di un buon compilatore di ottimizzazione) rispetto all'equivalente if (a > 33 | b < 54) {b++; ...} else b++;

ma ovviamente è possibile ottimizzarlo come segue (ma attenzione! questo ha un comportamento diverso in caso di overflow!): b++; if (a > 33 | b < 53) {...}