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

The practice of programming

---

Chapter 4 Interfaces

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.

Chapter 7 Performance

Before changing a program to make it  faster, be certain that it really is too slow, and use timing tools and profilers to discover where the time is going.

In any case, times have changed, and both main memory and secondary storage are amazingly cheap. Thus the first approach to optimizing space should be the same as to improving speed: don't  bother.

When you're trying to improve the speed or space consumption of a program, it's a good idea to make up some benchmark tests and problems so you can estimate and keep track of performance for yourself.

Chapter 8 Portability

Our message is this: try to write software that works within the intersection of the various standards, interfaces and environments it must accommodate. Don't fix every portability problem by adding special code; instead, adapt the software to work within the new constraints. Use abstraction and encapsulation to restrict and control unavoidable non-portable code. By staying within the intersection of constraints and by localizing system dependencies, your code will become cleaner and more general as it is ported.

• Language

1. Stick to the standard
2. Program in the mainstream
3. Be ware of language trouble spots......

• Headers and Libraries

1. Use standard libraries

• Program Organization

1. Use only features available everywhere
2. Avoid conditional compilation

• Isolation

1. Localize system dependencies in separate files
2. Hide system dependencies behind interfaces

• Data Exchange

1. Use text for data exch

• Byte Order

1. Use a fmed byte order for data exchange

• Portability and Upgrade

1. Change the name ifyou change the specification
2. Maintain compatibility with existing programs and data

• Internationalization

Chapter 9 Notation

• Regular Expressions

　　　The best-known regular expression tool is the program grep.

　　　Unfortunately, not every system comes with grep  or an equivalent. Some systems include a regular expression 　　　library, usually called regex  or regexp,  that you can use to write a version of grep.  If neither option is available, 　　　it's easy to implement a modest subset of the full regular expression language.

• Programs that Write Programs

• Using Macros to Generate Code

• Compiling on the Fly

---

Summary

The book generally introduces how to program practically, including the following topics:

• Style
• Algorithms and Data Structures
• Design and Implementation
• Interfaces
• Debugging
• Testing
• Performance
• Portability
• Notation

It emphasizes the practical problems we may meet in the programming. I think the most important thing is also practice, and learn by doing. Before we do, we need a general structure, a plan, a standard to help us better maintain, transmit a program. When we do, we need a good style, algorithms, and interfaces. When we finished, or half-finished, we need test, debug to improve it.

Some details need more studying because of my narrow knowledge. I'll look back this book from time to time.

That's all.