Yes, and even trying for a bitwise-or (which this is not) in this particular example is bad design. The explicit if-test as little proposed is what you want.
C programmers are well known to do a x|=0x0000FFF << 7 + 3 and other wacky stuff when simpler things work. Also bad form. Yes, I'm giving the meta-response, deal with it :)
| [reply] |
I could agree with "bad design" (I probably wouldn't in this particular instance - but it's certainly an arguable point).
However "something that doesn't even make sense" is a somewhat stronger statement than "bad design" :-)
The line makes complete sense as a numerical bitwise or, and the reason it does not do what the author expects is non-obvious in my opinion.
| [reply] |
However "something that doesn't even make sense" is a somewhat stronger statement than "bad design"
In some respects, I agree with the statement that the
original code as posted doesn't make sense. It "feels"
to me like something that would be posted as
Obfuscated Code, because instead of going about
solving the problem in any normal way, it attempts
to abuse certain lowlevel features of the dataset in
order to achieve a counterintuitive solution.
Normally, one would not expect to be able to compare
four numbers with a fifth number by bitwise or-ing
the four numbers together and comparing the result
to the fifth number. In the general case, this
would not work. It took me three readings of the
code to understand why the author *expected* it to
work. Of course, it doesn't, because he ignored
something else that is comparably low-level in
nature to the thing he was exploiting.
The code is attempting (and failing) to take
advantage of some lowlevel details not only of how
the language works but also lowlevel details of
the dataset and of the problem. If
256 weren't a power of two, there wouldn't even be
a presumption that it might work. It's a lowlevel
bit-fiddling dirty-trick (attempted) solution to a
higher-level problem, by no means a natural way
to go about the thing at hand. Notice I did not say
it isn't *the* natural way; I said it is not *a*
natural way at all. Id est, it doesn't make sense.
People who write code like this *deserve* to get
bitten by lowlevel details. (Of course, if you're
just fooling around and the results don't matter,
then getting bitten isn't such a big deal.)
;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
| [reply] |