Errata for the 2nd Edition of Refactoring

One thing I can always accurately predict about my books is that I will make mistakes. Here are the ones I know about for the second edition of Refactoring. If you spot something I don't have listed, let me know. Errors are fixed in later printings. They should be fixed in the web edition shortly after I record them here.

Errors in 1st and later printings

Page 2 (First Example: Starting Point): First sentence: "Image a company of theatrical players" should read "Imagine a company of theatrical players"

Page 32 (First Example: Status: Separated into Two Files (and Phases)):

In the code, the line

function renderPlainText(data, plays)

should read

function renderPlainText(data)

Page 39 (First Example: Making the Performance Calculator Polymorphic): First line, "createPerformanceData" should read "createStatementData"

Page 43 (First Example: Status: Creating the Data with the Polymoprhic Calculator): Second paragraph: "createPerformanceData" should read "createStatementData"

Page 68 (Principles: Automated Refactorings): In the second paragraph of the section "Brandt" should be spelled "Brant". (Sorry John, I seem to have a persistent blind spot with your name.)

Page 81 (Smells: Middle Man): Second paragraph, all text after "If there is additional behavior" should be deleted.

Page 135 (Encapsulate Variable): 3rd paragraph from bottom. "Now, any attempt to reassign the properties of the default owner will cause an error" should read "Now, any attempt to reassign the properties of the default owner will be ignored"

Page 142 (Introduce Parameter Object): Just above the last code sample. "adjust it to pass in the correct date range" should read "adjust it to pass in the correct temperature range"

Page 158 (Split Phase): In the 5th line of code, discount: discount should be highlighted

Page 162 (Encapsulate Record):

The first paragraph of the motivation section seems to have snuck off for a crafty pint in a local bar. It should read as follows:

Record structures are a common feature in programming languages. They provide an intuitive way to group related data together, allowing me to pass meaningful units of data rather than loose clumps. But simple record structures have disadvantages. The most annoying one is that they force me to clearly separate what is stored in the record from calculated values. Consider the notion of an inclusive range of integers. I can store this as {start: 1, end:5} or {start: 1, length:5} (or even {end: 5, length:5}, if I want to flaunt my contrariness). But whatever my store, I want to know what the start, end, and length are.

Page 219 (Move Statements to Callers):

Second line of second paragraph. "cut last line from renderPerson" should read "cut last line from emitPhotoData"

Page 251 (Replace Derived Variable with Query): Last paragraph, "I'd be inclined, however, to leave totalProductionAjustments..." should read ""I'd be inclined, however, to leave calculatedProductionAccumulator..."

Page 253 (Change Reference to Value):

In the line above the last code sample, "enhance the constructor to call the setters" should read "enhance the constructor to set these fields"

Page 263 (Consolidate Conditional Expression): In sketch, and code example at top of page 265. "isNotEligableForDisability" should be "isNotEligibleForDisability". (I originally made this error in the first edition, fixed it in the errata, and reintroduced it when writing the second.)

Page 295 (Introduce Special Case): Top paragraph, "I should be able to use Remove Dead Code on the global isPresent function" should read "I should be able to use Remove Dead Code on the global isUnknown function"

Page 405 (Bibliography): The ISBN for the [gof] reference should read 0201633612

Many thanks to Jeff Xiong, Umang Bhatt, Gautier Hayoun, Congyu Lin, Dmytro Pavliuchenko, Linhao Li 李霖灏, Ty Lewis, Akira Hirasawa, Masao Tomono and others I've forgotten for spotting and telling me about these errors