Pragmatic Programmer Tips, 20 - 43

Continuing with the tips given in the Pragmatic Programmer book. This is the second part of three. 


Pragmatic Programmer reference tips: 20 - 43


Chapter 3 - The Basic Tools
20.  Keep Knowledge in Plain Text
       Plain text won't become obsolete. It helps leverage your work and simplifies debugging 
       and testing.
21.  Use the Power of Command Shells
       Use the shell when graphical user interfaces don't cut it.
22.  Use a Single Editor Well
       The editor should be an extension of your hand; make sure your editor is configurable, 
       extensible, and programmable.
23.  Always Use Source Code Control
       Source code control is a time machine for your work—you can go back.
24.  Fix the Problem, Not the Blame
       It doesn't really matter whether the bug is your fault or someone else's—it is still your 
       problem, and it still needs to be fixed.
25.  Don't Panic When Debugging
       Take a deep breath and THINK! about what could be causing the bug.
26.  "select" Isn't Broken.
       It is rare to find a bug in the OS or the compiler, or even a third-party product or library. 
       The bug is most likely in the application.
27.  Don't Assume It—Prove It
       Prove your assumptions in the actual environment-- with real data and boundary conditions.
28.  Learn a Text Manipulation Language.
       You spend a large part of each day working with text. Why not have the computer do some 
       of it for you?
29.  Write Code That Writes Code
       Code generators increase your productivity and help avoid duplication.
30.  You Can't Write Perfect Software
       Software can't be perfect. Protect your code and users from the inevitable errors.


Chapter 4 - Pragmatic Paranoia
31.  Design with Contracts
       Use contracts to document and verify that code does no more and no less than it claims to do.
32.  Crash Early
       A dead program normally does a lot less damage than a crippled one.
33.  Use Assertions to Prevent the Impossible
       Assertions validate your assumptions. Use them to protect your code from an uncertain 
       world.
34.  Use Exceptions for Exceptional Problems
       Exceptions can suffer from all the readability and maintainability problems of classic 
       spaghetti code. Reserve exceptions for exceptional things.
35.  Finish What You Start
       Where possible, the routine or object that allocates a resource should be responsible for 
       deallocating it.


Chapter 5 - Bend, or Break
36.  Minimize Coupling Between Modules
       Avoid coupling by writing "shy" code and applying the Law of Demeter.
37.  Configure, Don't Integrate
       Implement technology choices for an application as configuration options, not through
       integration or engineering.
38.  Put Abstractions in Code, Details in Metadata
       Program for the general case, and put the specifics outside the compiled code base.
39.  Analyze Workflow to Improve Concurrency
       Exploit concurrency in your user's workflow
40.  Design Using Services
       Design in terms of services—independent, concurrent objects behind well-defined, 
       consistent interfaces.
41.  Always Design for Concurrency
       Allow for concurrency, and you'll design cleaner interfaces with fewer assumptions.
42.  Separate Views from Models
       Gain flexibility at low cost by designing your application in terms of models and views.
43.  Use Blackboards to Coordinate Workflow
       Use blackboards to coordinate disparate facts and agents, while maintaining independence 
       and isolation among participants.