The Pragmatic Programmer Chapter Notes 3 & 4

Continueing my book club notes on the the Pragmatic Programmer by Andrew Hunt and David Thomas.

Chapter 3

• The best way to store knowledge is in plain text, not binary blobs
• The drawback to plain text is that it comrpesses poorly, and may be expensive to process. This doesn’t seem particularly relevant with modern computers, but I suppose embeded systems still suffer this drawback.
• Plaintext helps insure against obsolescence and eases testing
• Shell beats GUI
• Get good at one editor until it’s like playing the piano
• Use source control (yeah we’re doing the obvious now)
• Embrace debugging as just another form of problem solving
• Turn your ego off when debugging. This is made possible by focusing on fixing the problem and not assigning blame
• Avoid panicing when debugging, accept that the bug is possible, resist the urge to fix the symptoms while leaving the cause
• You can only get so far with automated testing, at times its fastest to simply interview the user
• Rubber Ducking, attempt to explain the problem to someone else, if it’s a rubber duck
• Learn a scripting language (or these days, learn a systems language)
• Have code generators actively monitor and rebuild generated code

Chapter 4

• We are taught to code defensively and validate against bad input. We should also be defensive against ourselves
• Design by Contract (DBC). Define a contract of the pre-conditions for a method call and the guranteed post conditions that method promises. Contstraint invariantss to occuring only within the call itself.
• Be strict with the pre-conditions and make only small promises for the post conditions
• Crash early, don’t ignore an error or assume the system will resume stability once one occurs
• Use assertions to guarantee that events that won’t happen can’t happen. Keep assertions in production to detect these “impossible” events during operation (you won’t detect these during a normal test pass anyway)
• Exceptions should rarely be used as they interupt the program flow.
• If you remove all the exception handlers, then the code should crash.
• The routine that allocates a resource is responsible for deallocating it.