Find The Bug – Short Review
February 22nd, 2010The book “Find the Bug” by Adam Barr, to quote the author, “[...] contains 50 programs, in one of five languages (C, Java, Python, Perl, and x86 assembly language). Each program contains a single, hard-to-detect but realistic bug—no tricky gotchas.”. The idea is to train your ability to find bugs. The examples claim to be something you might be asked to do in a job interview. “Write me an algorithm to do $x!” and you move up to a whiteboard, write a few dozen lines in a language of your choosing (thus the 5 languages in the book) and now you must be able to defend it or critize it (depending on whether you are the interviewer or not). You don’t have test cases, you can’t compile it, you only have your brain.
This is a really neat idea in principle, but unfortunetaly, the execution is rather lacking. The enforced simplicity (every programm has to fit on one page) ignores many realistic kinds of bugs. None of the examples require much background knowledge, which at first looks like a good idea, but again is rather unrealistic. If I’m writing a level generator for a game and my random number generator has a bug, then I’ll probably only see it in some cases and finding it may require a bit of statistical knowledge. Just because I dislike statistics doesn’t mean I get to ignore them.
Especially bad is the fact that there are no performance optimizations. The code is always as clean and simple as it can be to solve the problem, but that’s not what real code looks like. In some cases, this is alright, but there are plenty of low-level function like memory allocation, string parsing or sorting and those normally have the hell optimized out of them. A “clever trick” is exactly the kind of thing that is widespread, evil and buggy.
Also, the examples sometimes aren’t really typical. The Python and Perl code in particular looks nothing like normal code.
The Python code is way too low-level, uses no list comprehension and barely anything of the extensive library. In short, it’s rather unpythonic and looks a lot more like quickly converted C code.
The Perl code has multiple comments and meaningful variable names, something no self-respecting Perl hacker would ever use. :>
It’s a bit hard to avoid because you can’t throw around all the neat little features everyone familiar with the language would use while still assuming that the reader has at best a passing knowledge themselves. It would have been a lot better to either stick with a common and small language (like C) or use pseudo code instead. Most bugs aren’t language specific anyway, so this wouldn’t have hurt the book.
Finally, some of the example code is just… strange. There is one Java example that wants to find out whether a year is a leap year or not. The relevant logic is this:
// A leap year is a multiple of 4, unless it is
// a multiple of 100, unless it is a multiple of
// 400.
//
// We calculate the three values, then make a
// 3-bit binary value out of them and look it up
// in results.
//
final boolean results[] =
{ false, false, false, false,
true, false, false, true };
if (results[
((((yearAsLong % 4) == 0) ? 1 : 0) << 2) +
((((yearAsLong % 100) == 0) ? 1 : 0) << 1) +
((((yearAsLong % 400) == 0) ? 1 : 0) << 0)]) {
throw new LeapYearException();
} else {
throw new NotLeapYearException();
}
If I ever meet anyone who uses something like this, then all my promises of non-violence will be void. However, it is a rather typical example of the twisted and mad code a Java programmer would write, so kudos to the author. It’s still an abomination, though.
Anyway, a lot of wasted potential. *sigh*
