Le probabilità sono che qualcuno che scrive (b * 42) | (~(b - 1) * 7) è qualcuno che sa molto poco della programmazione cercando di far finta di essere esperto / esperto / ecc. oppure qualcuno sta cercando di sabotare un progetto (cioè sono troppo esperti / esperti / intelligenti e vogliono la sicurezza del lavoro).
Il primo tipo di persona vuole dimostrare di sapere come usare NOT, OR, l'ordine delle operazioni, ecc. Stanno mostrando le loro conoscenze, ma, ahimè, stanno scrivendo codice che è molto meno efficiente, perché questo richiede due moltiplicazioni, una sottrazione, una non, e una o, che è chiaramente meno efficiente di un confronto, un paio di salti e un ritorno.
Se è così, non meritano di essere nel settore (ancora), ma la loro dimostrazione dimostra di conoscere la logica di base del computer e potrebbe essere una risorsa preziosa un giorno, una volta superata la mostra e iniziare a scrivere codice efficiente . Inoltre, esiste la netta possibilità che b non sia necessariamente 0 o 1, il che comporterebbe la restituzione di un valore completamente diverso. Questo potrebbe introdurre bug sottili che potrebbero essere difficili da trovare.
Il secondo tipo di persona spera di inserire un codice come questo (o molti altri tipi di codice subdolo), in modo che le persone continuino a porre loro domande sul codice, quindi sono considerate troppo preziose da perdere. Questo tipo di sabotaggio finirà per danneggiare un progetto, e dovrebbero essere lasciati andare immediatamente finché non impareranno la lezione e scrivere un codice ottimizzato e di facile lettura. C'è anche la possibilità che b non sia 1 o 0, come prima, il che significa che restituirà un valore diverso dal previsto (42 o 7), che può funzionare correttamente fino a quando qualche programmatore sfortunato lo cambia in if(b) ... else ... e il il codice smette improvvisamente di funzionare. Ad esempio, forse questo è un generatore di pseudo-numeri mascherato da una dichiarazione molto costosa.
Il codice leggibile è importante, oltre che privo di codice (per quanto pratico) dai bug logici come questo. Chiunque abbia scritto un codice seriamente per un po 'sa quanto sia importante. Scrivi un gioco completamente funzionale di Tic Tac Toe. Ora, metti da parte questo codice per un anno, poi torna ad esso e prova a leggere il codice. Se l'hai scritto in modo superficiale, senza riguardo per gli standard di codifica, i commenti, la documentazione, ecc. Probabilmente non riconoscerai nemmeno che il codice che hai scritto è stato digitato da te, tanto meno come risolverlo o aggiungere una nuova funzionalità se qualcosa è stato rotto o doveva essere aggiornato.
Quando più sviluppatori lavorano insieme, è ancora più importante che il codice sia leggibile, perché le probabilità sono che non si manterrà quel codice. Ti sarai spostato su altre cose e qualcun altro dovrà mantenere il tuo codice. Al contrario, potresti ereditare un altro progetto e spero che gli sviluppatori prima di lasciare commenti e codice pulito con cui lavorare. I programmatori che lavorano su codice affidabile scrivono il codice per essere manutenibile, compresi la leggibilità e i commenti.
Le prestazioni, anche se importanti, non dovrebbero prevalere sulla leggibilità. Come minimo, se qualcuno ha usato il secondo blocco di codice qui, mi aspetterei un lungo blocco di commenti che spieghi chiaramente perché lo hanno fatto in questo modo invece che in un modo più convenzionale. A quel punto, probabilmente avrei deciso di sostituirlo con un codice più convenzionale se non ci fosse una buona ragione per farlo. Se, in effetti, fosse una bomba logica, l'avrei riscritta in un modo più lungo quindi è chiaro che la funzione deve essere quella per evitare i bug, insieme a una documentazione chiara di ciò che realmente fa.
A quanto pare, sono abbastanza sicuro che ci sia un uso legittimo per qualche problema specializzato che per coincidenza ha bisogno di questo preciso algoritmo. Se è così, però, mi aspetterei commenti che spieghino l'algoritmo che usa questa logica, e sarebbe meglio che fosse per qualcosa di meglio di un blocco if-else. Gli unici due se-else blocchi appropriati per l'esempio specifico sono: if(b) return 42; return 7; (altrimenti è facoltativo) e return b? 42: 7; (gli operatori ternari sono a posto per la logica di piccolo ramo, a meno che gli standard di codifica non lo proibiscano interamente). Qualsiasi altra cosa è eccessivamente complicata e dovrebbe essere ridotta a una dichiarazione più semplice.
Di tanto in tanto mi ritrovo a scrivere codice "difficile" che gli sviluppatori più giovani potrebbero non capire immediatamente, e di solito commento quel codice in modo che possano capire perché è stato scritto così com'era. A volte il codice ottimizzato può essere difficile da leggere e tuttavia è necessario, ma questi dovrebbero essere l'eccezione piuttosto che la regola.
C'è, per coincidenza, un posto perfettamente accettabile per codice come questo. Concorsi di offuscamento. In tal caso, riserverei il giudizio per la funzione fino a quando non avessi determinato che il codice era solo un branch davvero ingegnoso, spreco di CPU, o se era un dispositivo più subdolo per generare numeri pseudo-casuali, il valore per PI (o qualche altro numero magico), o forse anche un debole algoritmo di crittografia.