As probabilidades são de que alguém escrevendo (b * 42) | (~(b - 1) * 7)
seja alguém que saiba muito pouco sobre programação tentando fingir ser experiente / experiente / etc, ou alguém tentando sabotar um projeto (ou seja, eles são muito experientes / experientes / inteligentes e quer segurança no emprego).
O primeiro tipo de pessoa quer mostrar que sabe usar NOT, OR, ordem de operações, etc. Eles estão mostrando seu conhecimento, mas, infelizmente, eles estão escrevendo código que é muito menos eficiente, porque isso requer duas multiplicações, uma subtração, uma não e uma ou, que é claramente menos eficiente do que uma comparação, um par pula e um retorno.
Se for esse o caso, eles não merecem estar na indústria (ainda), mas sua demonstração prova que eles sabem lógica básica do computador e podem ser um recurso valioso um dia, depois de passarem showboating e começarem a escrever código eficiente . Além disso, há a possibilidade distinta de que b não seja necessariamente 0 ou 1, o que resultaria em um valor completamente diferente sendo retornado. Isso pode introduzir bugs sutis que podem ser difíceis de encontrar.
O segundo tipo de pessoa espera inserir códigos como esse (ou muitos outros tipos desonestos de código), de modo que as pessoas continuem fazendo perguntas sobre o código, então eles são considerados valiosos demais para serem perdidos. Esse tipo de sabotagem acabará prejudicando um projeto, e eles devem ser liberados imediatamente até aprenderem a lição e escreverem um código otimizado e fácil de ler. Existe também a possibilidade de que b não seja 1 ou 0, como antes, o que significa que ele retornará um valor diferente do esperado (42 ou 7), o que pode funcionar corretamente até que algum programador infeliz o altere de volta para
if(b) ... else ...
e código de repente pára de funcionar. Por exemplo, talvez este seja um gerador de pseudo-número disfarçado como uma declaração if muito cara.
O código legível é importante, assim como o código livre (tanto quanto prático) de erros lógicos como este. Qualquer pessoa que esteja gravando código a sério sabe o quanto isso é importante. Escreva um jogo totalmente funcional de Tic Tac Toe. Agora, defina esse código por um ano, depois volte a ele e tente ler o código. Se você escreveu de forma informal, sem considerar padrões de codificação, comentários, documentação, etc, você provavelmente nem reconheceria que o código que você escreveu foi digitado por você, muito menos como consertá-lo ou adicionar um novo recurso se algo foi quebrado ou precisava ser atualizado.
Quando vários desenvolvedores trabalham juntos, é ainda mais importante que o código seja legível, porque as chances são de que você não mantenha esse código. Você terá passado para outras coisas e outra pessoa terá que manter seu código. Por outro lado, você pode herdar outro projeto e esperará que os desenvolvedores deixem comentários e códigos limpos para você trabalhar. Programadores trabalhando em código confiável escrevem o código para ser sustentável, incluindo legibilidade e comentários.
O desempenho, embora também importante, não deve ser mais uma questão de legibilidade. No mínimo, se alguém usou o segundo bloco de código aqui, eu esperaria um longo bloco de comentários que explicasse claramente por que eles fizeram dessa maneira ao invés de uma maneira mais convencional. Nesse ponto, eu provavelmente decidiria substituí-lo por um código mais convencional se não houvesse uma boa razão para isso. Se, de fato, fosse uma bomba lógica, eu a reescreveria de uma maneira mais longa, entendendo que a função tem que ser assim para evitar bugs, junto com uma documentação clara do que ela realmente faz.
Como se constata, tenho certeza de que há um uso legítimo de algum problema especializado que coincidentemente parece precisar desse algoritmo preciso. Se assim for, porém, eu esperaria comentários explicando o algoritmo que usa essa lógica, e é melhor que seja para algo melhor do que um bloco if-else. Os dois únicos blocos if-else apropriados para o exemplo específico são: if(b) return 42; return 7;
(else é opcional) e return b? 42: 7;
(os operadores ternários estão bem para a lógica de ramificação pequena, a menos que os padrões de codificação proíbam completamente). Qualquer outra coisa é excessivamente complicada e deve ser reduzida a uma declaração mais simples.
Ocasionalmente me vejo escrevendo código "complicado" que desenvolvedores mais jovens não entendem imediatamente, e eu costumo comentar esse código para que eles possam entender por que ele foi escrito da maneira que foi. Às vezes, o código otimizado pode ser difícil de ler e, no entanto, é necessário, mas essas devem ser a exceção e não a regra.
Existe, coincidentemente, um lugar perfeitamente aceitável para código como este. Concursos de ofuscação. Nesse caso, eu reservaria o julgamento para a função até que eu determinasse que o código era apenas uma ramificação realmente esperta, ou se era um dispositivo mais desonesto para gerar números pseudo-aleatórios, o valor para PI (ou algum outro número mágico), ou talvez até mesmo um algoritmo de criptografia fraco.