Odds are, someone writing
(b * 42) | (~(b - 1) * 7) is either someone who knows very little about programming trying to pretend to be experienced/knowledgeable/etc, or is someone trying to sabotage a project (i.e. they're too experienced/knowledgeable/intelligent and want job security).
The first type of person wants to show that they know how to use NOT, OR, order of operations, etc. They're showing off their knowledge, but, alas, they are writing code that's far less efficient, because this requires two multiplications, a subtraction, a not, and an or, which is clearly less efficient than a compare, a couple jumps, and a return.
If that's the case, they don't deserve to be in the industry (yet), but their demonstration proves they know basic computer logic and could be a valuable resource one day, once they get past showboating and start writing efficient code. Also, there's the distinct possibility that b won't necessarily be 0 or 1, which would result in a completely different value being returned. This could introduce subtle bugs that may be hard to find.
The second type of person hopes to slip in code like this (or many other devious types of code), so that people will keep asking them questions about the code, so they are deemed too valuable to lose. This type of sabotage will eventually hurt a project, and they should be let go immediately until they learn their lesson and write optimized, easy-to-read code. There's also the possibility that b won't be 1 or 0, as before, which means it will return a different value than expected (42 or 7), which may work correctly until some hapless programmer changes it back to
if(b) ... else ... and the code suddenly stops working. For example, maybe this is a pseudo-number generator disguised as a very expensive if statement.
Legible code is important, as well as code free (as much as practical) from logic bugs such as this one. Anyone that's seriously written code for a while knows how important this is. Write a fully functional game of Tic Tac Toe. Now, set this code aside for a year, then come back to it and try to read the code. If you wrote it offhandedly, without regards for coding standards, commenting, documentation, etc, you would probably not even recognize that the code you wrote was typed by you, much less how to fix it or add a new feature if something was broken or needed to be updated.
When multiple developers work together, it's even more important that code be legible, because odds are, you won't be maintaining that code. You'll have moved on to other things, and someone else will have to maintain your code. Conversely, you may inherit another project and you'll hope that the developers before you left comments and clean code for you to work with. Programmers working on reliable code write the code to be maintainable, including legibility and comments.
Performance, while also important, should not trump legibility. At minimum, if someone did use the second code block here, I'd expect a lengthy comment block that clearly explains why they did it this way instead of a more conventional manner. At that point, I'd probably decide to replace it with more conventional code if there was no good reason for it. If, indeed, it were a logic bomb, I'd re-write it in a longer fashion so it's understood that the function has to be that way to avoid bugs, along with clear documentation of what it really does.
As it turns out, I'm pretty sure that there is a legitimate use for some specialized problem that coincidentally works out to need this precise algorithm. If so, though, I'd expect comments explaining the algorithm that uses this logic, and it had better be for something better than an if-else block. The only two appropriate if-else blocks for the specific example are:
if(b) return 42; return 7; (else is optional) and
return b? 42: 7; (ternary operators are okay for small branch logic, unless coding standards forbid it entirely). Anything else is overly complicated and should be reduced a simpler statement.
I do occasionally find myself writing "tricky" code that more junior developers may not immediately understand, and I usually comment that code so they can understand why it was written the way it was. Sometimes optimized code can be hard to read, and yet is necessary, but these should be the exception rather than the rule.
There is, coincidentally, a perfectly acceptable place for code like this. Obfuscation contests. In that case, I'd reserve judgement for the function until I determined that the code was just a really clever, CPU-wasting branch, or if it was a more devious device for generating pseudo-random numbers, the value for PI (or some other magical number), or maybe even a weak encryption algorithm.
return b ? 42 : 7;Yes, the second example is unnecessarily obtuse if it is, in fact, equivalent to the first.
||instead of bitwise or
|, assuming short-circuit evaluation. And assuming b is always either 0 or 1. Which just underscores the importance of testable, readable code. There is always "Job Security" for those who end up cleaning up this kind of mess.