Quotes and Notes from 'Becoming a Better Programmer' - Chapters 2-8

From O'Reilly e-book:
Becoming a Better Programmer by Pete Goodliffe

Chapter 2

• KEY ➤ Remember who you’re writing code for: other people. (p.9)
• page 10:

Some programmers like to present banner comments in pretty ASCII-art boxes:
/**************************************************
* This is a pretty comment. *
* Note that there are asterisks on the *
* righthand side of the box. Wow; it looks neat. *
* Hope I never have to fix this tiypo. *
**************************************************/

...Frankly, this is a sadistic presentation style.

• Also on p.10, he says to write code as you would prose. "Functions are akin to chapters."
• Within the chapters, related lines of code are equivalent to paragraphs.
• Insert blank lines only between these conceptual paragraphs, not within them
• Don't have too many of these "paragraphs" per function

• If you clean up code, make that a separate commit from any changes to the code's behavior.
  KEY ➤ Never alter presentation and behaviour at the same time. Make
  them separate version-controlled changes. (p.14)

Chapter 3

• (p.18) There are many reasons why unnecessary code is the root of all evil...
• Writing a fresh line of code is the birth of a little life form.
• ...
• Code harbours bugs. The more code you have, the more places there are for bugs
  to hide.
• Refactoring (p.20) 
• A refactor is only a refactor if it is a transformation of the source code, preserving behaviour.
•  the DRY principle: Don’t Repeat Yourself!
• ...factoring similar code into a shared function introduces tight coupling...
  They both now rely on a shared interface;...
  —so DRY your code responsibly! (p.21)
• Dead code is code that is never run, that can never be reached...
• Tell your code to get a life, or get lost. (p.23)
• The code itself says what and how. A comment should explain why..(p.24)
• Do not remove code by commenting it out. (p.24)
• Remove code completely. 
• You can always get it back afterwards from your source control
  system.

Chapter 4

• YAGNI = You Aren’t Gonna Need It: (p.29)
• Don't write..code you think is going to be needed in future versions. 
• Don’t write it now if you don’t need it now. 
• Much "debug" code is necrotic...unsightly scaffolding that hides the beautiful architecture underneath. (p.31)
• It is harder to refactor, simplify, or optimise your program when it is bogged down
  by zombie code. (p.32)
• Don’t add “minor”features that you think are interesting, but no one has asked for. They’ll be easy enough to add later, if they are required. Even if it seems like a good idea. Don’t do it. (p.33)  That one is hard to resist. :^)

Chapter 6

• ...try adding a single, one-line, failing test. Does the test suite immediately fail? This smoke test proves that the tests are not actively being ignored. (p.50)
  

Chapter 7

• I know I shouldn’t moan, but sometimes I swear that programmers shouldn’t be allowed
  to type the word thread without first obtaining a license to wield such a dangerous
  weapon. (p.56)
• ...if it has been working adequately for years without tinkering, it is probably inappropriate to “tidy it up” now, especially if you’re unlikely to need to make many more changes in the future. (p.58) 
• KEY ➤ Make code changes slowly, and carefully. Make one change at a time. (p.58)
• ...the unreadable mess of special cases might be like that for a reason. Each bodge and code hack encodes an important piece of functionality that has been uncovered through bitter
  experience. Ignore these subtle behaviours at your peril. (p.59)
• The effective programmer does not only deal well with the bad code, but also with the people that wrote it. (p.60)
• “refactored the code to look neater.” -> “refactored code back to working.” (p.60)

Chapter 8: 

• Don't ignore:
• Return codes -  e.g. printf
• Side effects - e.g. errno - which is a mess when code is threaded
• Exceptions

try
{
    // ...do something...
}
catch (...) {} // ignore errors
The saving grace of this awful construct is that it highlights the fact you’re doing
something morally dubious. (p.64)

• Understand your language’s idioms and requirements for effective exception use. (p.65)