程序设计实践（英文版）

3.1 The Markov Chain Algorithm
3.2 Data Structure Altematives
3.3 Building the Data Structure in C
3.4 Generating Output
3.5 Java
3.6 C++
3.7 Awk and Perl
3.8 Performance
3.9 Lessons
Chapter 4: Interfaces
4.1 Comma-Separated Values
4.2 A Prototype Library
4.3 A Library for Others
4.4 A C++ Implementation
4.5 Interface Principles
4.6 Resource Management
4.7 Abort, Retry, Fail?
4.8 User Interfaces
Chapter 5: Debugging
5.2 Debuggers
5.2 Good Clues, Easy Bugs
5.3 No Clues, Hard Bugs
5.4 Last Resorts
5.5 Non-reproducible Bugs
5.6 Debugging Tools
5.7 Other People's Bugs
5.8 Summary
Chapter 6: Testing
6.1 Test as You Write the Code
6.2 Systematic Testing
6.3 Test Automation
6.4 Test Scaffolds
6.5 Stress Tests
6.6 Tips for Testing
6.7 Who Does the Testing?
6.8 Testing the Markov Program
6.9 Summary
Chapter 7: Performance
7.1 A Bottleneck
7.2 Timing and Profiling
7.3 Strategies for Speed
7.4 Tuning the Code
7.5 Space Efficiency
7.6 Estimation
7.7 Summary
Chapter 8: Portability
8.1 Language
8.2 Headers and Libraries
8.3 Program Organization
8.4 Isolation
8.5 Data Exchange
8.6 Byte Order
8.7 Portability and Upgrade
8.8 Internationalization
8.9 Summary
Chapter 9: Notation
9. 1 Formatting Data
9.2 Regular Expressions
9.3 Programmab1e Tools
9.4 InterPreters, Compilers, and Virtual Machines
9.5 Programs that Write Programs
9.6 Using Macros to Generate Code
9.7 Compiling on the Fly
Epilogue
Appendix: Collected Rules
Index

.　　 Much as we try to write programs correctly the first time, bugs, and therefore debugging, are inevitable. Chapter 5 gives strategies and tactics for systematic and effective debugging. Among the topics are the signatures of common bugs and the importance of "numerology," where patterns in debugging output often indicate where a problem lies.
　　 Testing is an attempt to deve1op a reasonable assurance that a program is working correctly and that it stays correct as it evolves. The emphasis in Chapter 6 is on systematic testing by hand and machine. Boundary condition tests probe at potential weak spots. Mechanization and test scaffolds make it easy to do extensive testing with modest effort. Stress tests provide a different kind of testing than typical users do and ferret out a different class of bugs.
　　 Computers are so fast and cornpi1ers are so good that many programs are fast enough the day they are written. But others are too slow, or they use too much memory, or both. Chapter 7 presents an orderly way to approach the task of making a program use resources effcientIy, so that the program remains correct and sound as it is made more efficient.
　　 Chapter 8 covers portability. Successful programs live long enough that their environment changes, or they must be moved to new systems or new hardware or new countries. The goal of portabi1ity is to reduce the majntenance of a program by minimizing the amount of change necessary to adapt it to a new environment.
　　 Computing is rich in languages, not just the general-purpose ones that we use for the bulk of programming, but also many specialized languages that focus on narrow domains. Chapter 9 presents several examples of the importance of notation in computing, and shows how we can use it to simplify programs, to guide implementations,and even tO help us write programs that write programs.
　　 To talk about programming, we have to show a lot of code. Most of the examples were written expressly for the book, although some smaIl ones were adapted from other sources. We've tried hard to write our own code we1l, and have tested it on half a dozen systems directly from the machine-readable text. More information is available at the web site fOr The Practice Of Programming:
　　 http: //tpop. aw1. com
　　 The majority of the programs are in C, with a number of examples in C++ and Java and some brief excursions into scripting languages. At the lowest level, C and C++ are almost identical and our C programs are valid C++ programs as well. C++and Java are lineal descendants of C, sharing more than a little of its syntax and much of its efficiency and expressiveness, while adding richer type systems and libraries.In our own work, we routinely use aIl three of these languages, and many others. The choice of language depends on the problem: operating systems are best writtCn in an efficient and unrestrictive language like C or C++, quick prototypes are often easiest in a command interpreter or a scripting language like Awk or Perl; for user interfaces, Visual Basic and Tcl/Tk are strong contenders, along with Java.
　　 There is an irnportant pedagogical issue in choosing a language for our examples.Just as no language soIves all problems equal1y well, no single language is best for presenting aIl topics. Higher-level languages preempt some design decisions. lf we use a lower-level language, we get to consider alternative answers to the questions, by exposing more of the detaiIs, we can talk about them better. Experience shows that even when we use the facilities of high-Ievel languages, it's invaluable to know how they relate to lower-level issues, without that insight, it's easy to run into performance problems and mysterious behavior. So we will often use C for our examples, even though in practice we might choose something else.
　　 For the most part, however, the lessons are independent of any particular programming language. The choice of data structure is affected by the language at hand; there may be few options in some languages while others might support a variety of alternatives. But the way to approach making the choice will be the same. The details of how to test and debug are different in different languages, but strategies and tactics are similar in all. Most of the techniques for making a program efficient can be applied in any language.
　　 Whatever language you write in. your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. We hope that, no matter what your current experience and skill, this book will help you to prograhi better and enjoy it more.
　　 We are deepIy grateful to friends and colleagues who read drafts of the manuscript and gave us many helpful comments. Jon Bentley, Russ Cox, John Lakos, John Linderman, Peter Memishian, Ian Lance Taylor, Howard Trickey, and Chris Van Wyk read the manuscript, some more than once, with exceptional care and thoroughness.
　　We are indebted to Tom Cargi1l, Chris Cleeland, Steve Dewhurst, Eric Grosse,Andrew Herron, Gerard Holzmann, Doug Mcllroy, Paul McNamee, Peter Nelson,Dennis Ritchie, Rich Stevens, Tom Szymanski, Kentaro Toyama, John Wait, DanielC. Wang, Peter Weinberger, Margaret Wright, and Cliff Young for invaluable comments on drafts at various stages. We also appreciate good advice and thoughtful suggestions from Al Aho, Ken Arnold, Chuck Bigelow, Joshua B1och, Bill Coughran,Bob Flandrena, Renee French, Mark Kernighan, Andy Koenig, Sape Mullender, Evi Nemeth, Marty Rabinowitz, Mark V. Shaney, Bjarne Stroustrup, Ken Thompson, and Phil Wadler. Thank you all.
　　Brian W Kernighan
　　Rob Pike