There is a showstopper bug that is hard to reproduce they effectively bisect the code until they find it.
They fix the bug. He is asked whose error it was by his boss, and to protect the person, he says it’s not important. His bonus - keep in mind he created a new successful IP from scratch - is drastically reduced as a result.
Some dev had put the classic `<=` instead of `<` in a for loop check and the for loop body promptly corrupted some memory leading to heisencrashes. It took weeks to narrow down with 10+ hour days. Once they did and fixed it the boss asked for a name who had written the offending code. Timothy did not bend. Boss was salty and cut his bonus.
Nothing wrong with a do...while loop, but I've learned to look twice when crossing that particular street. Most loops that don't have bugs tend to support zero iterations seamlessly and inherently.
Being able to choose the right control structure (and data structures) can provide additional information to the correctness of the code than arbitrary choices which may perform the same function. Choosing the Most expressive options may or may not conflict with performance, in which case, comments are helpful to describe why more obvious approaches weren’t taken.
The thread had had one poster state they find <= suspicious in a for loop, and another about any do-while loop. I don't think these are literally the same thing (hence "if you squint") but I think they share a meaningful similarity of adding an extra pass through the loop compared to the other form and I thought that was interesting.
In a low-level sense, branch-if-greater-or-equal is one instruction even on RISC machines — and not one any more "complex" than branch-if-greater.
In an abstract boolean-algebra sense, x <= y is the same as !(x > y).
i.e. two tests, or perhaps i should say logical operations. i'm not saying don't use '<=', but do check that it is doing what you think it should.
if: x <= y, do: foo(), else: nothing()
if: y < x, do: nothing(), else: foo()
if: y > x, do: nothing(), else: foo()
Might as well just do (x != y); unless you're specifically looking to guard against erroneous bitflips that would be caught by the prior (x < y), but not the former. But at that point -- it's likely your result is going to be garbage.
In essence they're the same; but one you never have to think about whether you're using it correctly.
Can anyone find a reason not to swap out (x < y) for (x != y)?
Example: The loop should run as long as the counter is smaller than 10. `i /= 10` achieves the same thing but communicates something very different. It implies `i` may be changed inside the loop to become larger than 10. The condition itself implies a larger valid state space.
It's a moot point anyway. Modern languages have much better looping constructs.
One might argue corrupting much larger swathes of memory is better from a "fail-fast" perspective, but there's always tradeoffs.