Va sempre bene che un condizionale abbia degli effetti collaterali? [chiuso]

C'è un effetto collaterale semi-condizionale uno posso pensare che sia okay: while(iter.MoveNext())

Detto questo, penso che questo rientri principalmente nella categoria " mai è una categoria molto grande". Posso pensare ad alcuni casi rari in cui l'ho visto accettabile, ma in generale questo è vile e da evitare.

Non riesco nemmeno a pensare a uno scenario in cui quella particolare riga sarebbe accettabile, ma non riesco nemmeno a pensare a uno scenario in cui quella particolare riga sarebbe utile , quindi è difficile immaginare il contesto è in.

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

Ora, considera quanto segue:

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

E confronta:

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

Evitare l'effetto collaterale (la lettura) nelle condizioni aiuta a migliorare la leggibilità; o ha appena duplicato il codice e aggiunto ingombri?

Non è corretto che una condizione abbia effetti collaterali (se questo rende il codice meno leggibile) ed è anche OK se una condizione ha effetti collaterali (se questo rende il codice più leggibile). Il fattore chiave è la "leggibilità". Tutto il resto sono regole create dagli sciocchi in un tentativo errato di migliorare la leggibilità (mentre spesso ha 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 un'espressione if sempre ha portato a un codice peggiore, allora non sarebbe legale creare tali espressioni. I progettisti di linguaggi possono essere uomini ideosincratici e fallibili, ma non sono che stupidi.

Detto questo, quali sono gli esempi di effetti collaterali giustificati in un if ? Ad esempio, supponiamo di essere legalmente obbligato a registrare tutti gli accessi alla proprietà P di un'entità E a fini di controllo. (Immagina di lavorare in un impianto di arricchimento dell'uranio e ci sono controlli legali molto severi su cosa il tuo codice è autorizzato a fare e su come dovrebbe farlo.) Quindi qualsiasi if che controlla quella proprietà causerà il lato effetto del registro di controllo esteso.

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

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

Sebbene sia un codice molto 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 al seguente (ma attenzione! questo ha un comportamento diverso in caso di overflow!): b++; if (a > 33 | b < 53) {...}