Lo más probable es que alguien que escribe (b * 42) | (~(b - 1) * 7) sea alguien que sepa muy poco acerca de la programación que trata de pretender tener experiencia / conocimiento / etc, o alguien que intente sabotear un proyecto (es decir, que tenga demasiada experiencia / conocimiento / inteligencia) y quiero seguridad en el empleo).
El primer tipo de persona quiere mostrar que sabe cómo usar NO, O, orden de operaciones, etc. Están demostrando su conocimiento, pero, por desgracia, están escribiendo un código que es mucho menos eficiente, porque esto requiere dos multiplicaciones, una resta, una no y una o, que es claramente menos eficiente que una comparación, un par de saltos y una devolución.
Si ese es el caso, no merecen estar en la industria (todavía), pero su demostración demuestra que conocen la lógica básica de la computadora y que podrían ser un recurso valioso algún día, una vez que superen el showboating y comiencen a escribir código eficiente . Además, existe la clara posibilidad de que b no necesariamente sea 0 o 1, lo que daría como resultado que se devuelva un valor completamente diferente. Esto podría introducir errores sutiles que pueden ser difíciles de encontrar.
El segundo tipo de persona espera introducir un código como este (o muchos otros tipos de código tortuosos), para que las personas sigan haciéndoles preguntas sobre el código, por lo que se consideran demasiado valiosas para perderlas. Este tipo de sabotaje terminará dañando un proyecto, y se les debe dejar ir de inmediato hasta que aprendan la lección y escriban un código optimizado y fácil de leer. También existe la posibilidad de que b no sea 1 o 0, como antes, lo que significa que devolverá un valor diferente al esperado (42 o 7), que puede funcionar correctamente hasta que algún programador desafortunado lo vuelva a cambiar a if(b) ... else ... y el código de repente deja de funcionar. Por ejemplo, tal vez este es un generador de pseudo-números disfrazado como una declaración muy costosa si.
El código legible es importante, así como el código libre (tan práctico) de errores lógicos como este. Cualquiera que haya escrito un código serio durante un tiempo sabe lo importante que es esto. Escribe un juego completamente funcional de Tic Tac Toe. Ahora, ponga este código a un lado por un año, luego vuelva a él e intente leer el código. Si lo escribiera por casualidad, sin tener en cuenta los estándares de codificación, los comentarios, la documentación, etc., es probable que ni siquiera reconozca que escribió el código que escribió, y mucho menos cómo solucionarlo o agregar una nueva función si se rompe algo. necesitaba ser actualizado.
Cuando varios desarrolladores trabajan juntos, es aún más importante que el código sea legible, porque las probabilidades son que no mantendrás ese código. Se habrá mudado a otras cosas, y alguien más tendrá que mantener su código. A la inversa, puede heredar otro proyecto y esperará que los desarrolladores antes de dejar comentarios y código limpio puedan trabajar con usted. Los programadores que trabajan en un código confiable escriben el código que se puede mantener, incluidos la legibilidad y los comentarios.
El rendimiento, aunque también es importante, no debe superar la legibilidad. Como mínimo, si alguien usara el segundo bloque de código aquí, esperaría un bloque de comentarios largo que explique claramente por qué lo hicieron de esta manera en lugar de una manera más convencional. En ese momento, probablemente decidiría reemplazarlo con un código más convencional si no hubiera una buena razón para ello. Si, de hecho, fuera una bomba lógica, la reescribiría de una manera más larga para que se entienda que la función debe ser de esa forma para evitar errores, junto con una documentación clara de lo que realmente hace.
Resulta que estoy bastante seguro de que existe un uso legítimo para un problema especializado que, por casualidad, funciona para necesitar este algoritmo preciso. Sin embargo, si es así, esperaría comentarios que expliquen el algoritmo que usa esta lógica, y es mejor que sea para algo mejor que un bloque if-else. Los únicos dos bloques if-else apropiados para el ejemplo específico son: if(b) return 42; return 7; (de lo contrario es opcional) y return b? 42: 7; (los operadores ternarios están bien para la lógica de ramificación pequeña, a menos que los estándares de codificación lo prohíban por completo). Cualquier otra cosa es demasiado complicada y debería reducirse a una declaración más simple.
Ocasionalmente, me encuentro escribiendo un código "complicado" que los desarrolladores más jóvenes pueden no entender de inmediato, y generalmente comento ese código para que puedan entender por qué se escribió de la manera en que lo fue. A veces, el código optimizado puede ser difícil de leer y, sin embargo, es necesario, pero esta debería ser la excepción y no la regla.
Hay, casualmente, un lugar perfectamente aceptable para un código como este. Concursos de ofuscación. En ese caso, me reservaría un criterio para la función hasta que determinara que el código era simplemente una rama muy inteligente que desperdiciaba la CPU, o si era un dispositivo más desviado para generar números pseudoaleatorios, el valor para PI (o algún otro número mágico), o tal vez incluso un algoritmo de cifrado débil.