muflax65ngodyewp.onion/content_muflax/software/find_the_bug.mkd

---
title: "Review: Find the Bug"
date: 2010-02-22
techne: :done
episteme: :believed
---

The 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:

~~~
#!java
// 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\*