Errata

Beautiful Code

Errata for Beautiful Code

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date Submitted
Printed Page 116
example 8-2

line 13, instead of:
int yFilter = iFilter / cyFilter;
should be:
int yFilter = iFilter / cxFilter;

(the row doesn't depend on the height of the filter, but on the width, consistent with the xFilter of line 14 being "% cxFilter")

In addition - another possible bug is in lines 16 - 19 - it seems that since it filters on a flat array, the filter wraps around rows, which might not be the desired behavior. (i.e. pixel [i, stride - 1] will be affected by pixel [i + 1, 0]



 Eran Yarkon  Dec 27, 2020 
Printed Page 459
while loop

Two separate iterators are used in parallel to independently iterate through the keys and values of the HashMap while it is intended to use togehter keys and their /associated/ values. This is based on the assumption that both iterators traverse the map's entry set in identical order, so both sequences are aligned. While this is a reasonable assumption, it is not a guaranteed behaviour of HashMap and thus may lead to subtle errors once its implementation changes.

Also, the code, when read, doesn't tell what it is really intended to do, which is: "We're iterating through all key-value pairs, doing something with the key and the value." Instead, it tells a different story: "We're iterating over the values and do something with them and keys taken from another sequence." This needlessly obscures the idea behind the code.

To overcome both problems, I suggest using a single iterator on the map's entry set, retrieving key and associated value explicitly from every key-value pair yielded. This may be a bit more verbose but makes the intention clear and prevents subtle bugs from creeping in at some time.

 Hartmut Schäfer  Dec 04, 2014 
Other Digital Version 109
Third paragraph after "Introducing JUnit"

"Extreme Programming" is spelled "eXtreme Programming" but it should be spelled with a capital "E" and a lowercase "x".

 shlomif  Apr 27, 2012 
Other Digital Version 101
5th paragraph

"HMTL document" should be "HTML document". This is in the chapter about FIT.

 shlomif  Apr 23, 2012 
Printed, Page 505
4th paragraph

Second sentence begins "Som when I sat down...". This should read "So when I sat down...".

 William Pollock  Sep 14, 2011 
Printed, Page 440
Last code example, bottom of page

On line 3, "logfile _" should be "logfile_" (remove extra space)

 William Pollock  Aug 01, 2011 
Printed Page 471-472
Example 28-1

Further to the unconfirmed errata of Oct 2010 ...

The variable "offset" is of no use at all since all of the if(...) alternatives break out of the inner loop if taken. This means offset is always zero inside the inner loop, which means the variable i is of no use either since it always evaluates/equates to j (i.e. the statement i=(j+offset)%n is meaningless).

In short, the logic of the delta debugging algorithm is badly flawed, and even trying to account for these problems, I'm not sure that it is even correct at all.

 Anonymous  Jul 22, 2011 
Printed, Page 431
Figure 26-1

In the code snippet above system "Balar", I would expect only one open parenthesis after "log_message", not two.

 William Pollock  Jul 08, 2011 
Printed, Page 431
1st paragraph

Last sentence begins "It also provide...". It should be "It also provides...".

 William Pollock  Jun 28, 2011 
Printed, Page 279
First paragraph

If Mr. Spinellis started in Athens, would he not first travel west to Frankfurt, and then east to Shanghai or Bangalore?

 William Pollock  May 16, 2011 
Printed Page 472
EXAMPLE 28-1.

The use of the variable "offset" seems completely broken.

We have two times "offset = i; break" in the inner while loop.
This does not make any sense, because offset will be reset to
0 afterwards.

Is this supposed to be "offset = i" without the "break"?

 Anonymous  Oct 28, 2010 
Printed Page 271
Last paragraph

In the sentence:
Based on the definition of the struct usb_interface recently shown, the dev variable is probably placed 16 bytes into the structure on a 32-bit processor.
The correct displacement would be 20 for most 32 bit architectures (2 * 32 bit pointers and 3 * 32 bit int preceding, no alignment issues)

 John Dickson  Jul 02, 2010 
Printed Page 132
2nd Line

s = object(original_symbol);

should be:

s = Object(original_symbol);

 Scott Hamilton  May 29, 2010 
Printed Page 109
Table 8-2

There is no Destination (D) Input parameter.

 Norman Shulman  Apr 11, 2010