Book Review of “The practice of programming” (Ⅳ)

The practice of programming

A good programmer should always be good at designing. The essence of design is to balance competing goals and constraints. When we do programming, we need to design a friendly, portable and flexible interface.

Among the issues to be worked out in a design are:

　　interfaces,  information hiding,  resource management,  error handling

These factors are not separated, but combined.

So, how to do a good designer? On the other word, how to handle the issues above perfectly?

The first step is to construct a general frame, leaving out the details. Then we need to test it by thinking of every possible situation, and improve it. By the way, it is essential for our frame to work in changeable environments. In this circumstance, we need specifications to constraint our work. Generally speaking, specifications had better be worked out in advance.

To prosper an interface must be well suited for its task-simple, general, regular,predictable, robust-and it must adapt gracefully as its users and its implementation change.

• Hide implementation details
• Avoid global variables
• Don‘t reach behind the user‘s back
• Do the same thing the same way everywhere

About Resource Management:

• Initializationma
• Maintaining state
• Sharing and copying
• Cleaning up (Free a resource in the same layer that allocated it)

To avoid problems, it is necessary to write code that is reentrant,  which means that it works regardless of the number of simultaneous executions.

The text of error messages, prompts, and dialog boxes should state the form of valid input.

Charpter 5 Debugging

• Good Clues

1. Look for familiar patterns
2. Examine the most recent change
3. Don‘t make the same mistake twice
4. Debug it now, not later
5. Get a stack trace
6. Read before typing
7. Explain your code to someone else

• No Clues

1. Make the bug reproducible
2. Divide and conquer
3. Study the numerology of failures
4. Display output to localize your search
5. Write self-checking code
6. Write a logfile
7. Draw a picture
8. Use tools
9. Keep records

• Last Resorts

  This may be  the time to use a good debugger to step through the program.

• Non-reproducible Bugs

1. Check whether all variables have been initialized
2. If the bug changes behavior or even disappears when debugging code is added, it may be a memory allocation error

Chapter 6 Testing

• Test as You Write the Code

1. Test code at its boundaries
2. Test pre- and post-conditions
3. Use assertions
4. Program defensively
5. Check error returns

• Systematic Testing

1. Test incrementally
2. Test simple parts first
3. Know what output to expect
4. Verify conservation properties
5. Compare independent implementations
6. Measure test coverage

• Test Automation

1. Automate regression testing
2. Create self-contained tests

• Test Scaffolds
• Stress Tests
• Tips for Testing

1. Programs should check array bounds (if the language doesn‘t do it for them), but the checking code might not be tested if the array sizes are large compared to typical input.
2. Make the hash function return a constant, so every elemen1 gets installed in the same hash bucket.
3. Write a version of your storage allocator that intentionally fails early, to test your code for recovering from out-of-memory errors.
4. Before you ship your code. disable testing limitations that will affect performance.
5. Initialize arrays and variables with some distinctive value, rather than the usual default of zero; then if you access out of bounds or pick up an uninitialized variable, you are more likely to notice it.
6. Vary your test cases
7. Provide ways to make the amount and type of output controllable when a program is run; extra output can help during testing.
8. Test on multiple machines, compilers, and operating systems.