This is the first book review I've done since middle school, so please bear with the somewhat free-form style :)
First off, I liked the book, and I'd heartily recommend it to groups that are doing code reviews as a primer.
In "Find the Bug", Adam presents 50 vaguely real world examples of code bugs that are likely to be found only by debugging or careful code inspection. He spreads the bugs across five different languages (C, Java, Python, Perl, and x86 assembly), providing ten different bugs in each.
The book is organized into five different sections, one for each language. Each section contains a brief primer on the language, basically enough information for a reader unfamiliar with the language to be able to determine the bug even if they don't know the language (for instance, I don't know Python, but was able to find most of the bugs in the python section after reading the language overview).
For each bug, Adam follows a basic template. He starts with a brief description of the purpose of the function (sorting entries, searching for values, playing LIFE, playing go fish, etc), the code for the function, a series of questions about the code, and a series of hints to aid in the process of determining the bug. Finally, he explains the origin of the bug and presents the corrections needed for the bug.
Adam does a good job of presenting a fairly broad set of potential bugs, and given the diverse languages that he presents, there are opportunities for people to develop their code reviewing skills in a series of different languages.
Adam has a good writing style (as shown in his previous blook Proudly Serving my Corporate Masters), and it carries forward in this book - the examples are well written and read easily.
One thing I did not like about the book was the bug classification system. Adam categorizes all the bugs in the book according to a taxonomy of bugs based roughly on the taxonomy that Donald Knuth used for TeX. Personally, I found the taxonomy rather distracting. Especially since the taxonomy of some of the bugs wasn't clear - for instance, bug 7.2 (assembly language, multiply two numbers using shifts) could be either F.location or A.logic depending on how you wanted to classify them.
It's also clear that Adam's not an assembly language programmer. I was cringing reading some of the assembly language sections (especially the multiply using shifts example) because the code looked "wrong" to my eyes. Essentially, the root of the problem was that Adam didn't use some of the "standard" tricks that a seasoned assembly language programmer would use. For instance he had a loop where he used a TEST ECX, ECX/JNZ <destination> - an assembly language programmer would use JECXZ <temporary label ahead of the jmp>/JMP <destination> instead (because JCXZ doesn't change the flags register). He also zeroed registers using MOV EAX, 0 instead of XOR EAX, EAX (which results in slightly smaller code). These are total nits however :).
Find the Bug's not a good general purpose textbook, but, as I said, it's a really good primer to help hone code reviewing techniques. It's going to stay on the bookshelf.
I give it a thumbs up :)
Oh, and I've got to point out the Kanji Backspace problem (sorry Adam, I had to point it out). This is problem 3.10 (C language, Kanji Backspace). Adam's blogged about this one, but the upshot is that we had a disagreement about the Kanji Backspace algorithm as presented in his book - the algorithm does work, but the code as presented doesn't correctly identify Kanji lead byte characters. The algorithm specified also also only works for DBCS character sets like Kanji - it doesn't work for general purpose multi-byte character sets.
Title: Find the BugAuthor: Adam BarrISBN: 0-321-22391-8
Full Disclosure: Adam's a friend of mine, we've known each other for at least 12 years now.
Edit: Removed nonexistant JECXNZ instruction, thanks Benny.