With the same insight and authority that made their book The Unix Programming Environment a classic, Brian Kernighan and Rob Pike have written The Practice of Programming to help make individual programmers more effective and productive.
　　The practice of programming is more than just writing code. Programmers must also assess tradeoffs,Choose among design alternatives, debug and test, improve performance, and maintain software written bythemselves and others. At the same time, they must be concerned with issues like compatibility robustness,and reliability while meeting specifications.

Have you ever...
　　●wasted a lot of time coding the wrong algorithm
　　●used a data structure that was much too complicated
　　●tested a program but missed an obvious problem
　　●spent a day looking for a bug you should have found in five minutes
　　●needed to make a program run three times faster and use less memory
　　●struggled to move a program from a workstation to a PC or vice versa
　　●tried to make a modest change in someone else's program
　　●rewritten a program because you couldn't understand it
　　● Was it fun
　　These things happen to programmers all the time. But dealing with such problems is often harder than it should be because topics like testing, debugging, portability, performance, design altematives, and style--the practice of programming--are not usually the focus of computer science or programming courses. Most programmers learn them haphazardly as their experience grows, and a few never learn them at all.In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles--simplicity, clarity, generality--that form the bedrock of good software. One can also overlook the value of tooIs and notations that mechanize some of software creation and thus enlist the computer in its own programming.
　　Our approach in this book is based on these underlying, interrelated principles,which apply at all levels of computing. These include simplicity, which keeps programs short and manageable; clarity, which makes sure they are easy to understand,for people as well as machines; generality, which means they work well in a broad range of situations and adapt well as new situations arise; and automation, which lets the machine do the work fOr us, freeing us from mundane tasks. By looking at computer programming in a variety of languages, from algorithms and data structures through design, debugging, testing, and performance improvement, we can illustrate universal engineering concepts that are independent of language, operating system, or programIning paradigm.
　　This book comes from many years of experience writing and maintaining a lot of sotiware, teaching programming courses, and working with a wide variety of programmers. We want to share lessons about practical issues, to pass on insights from our experience, and to suggest ways for progran1mers of a1I levels to be more proficient and productivc.
　　We are writing for several ki11ds of readers. If you are a student who has taken a programming course or two and would like to be a better programmer, this book will expand on some of the topics fOr which there wasn't enough time in school. If you write programs as part of your work. but in support of other activities rather than as the goal in itself, the information will help you to program more effectively. If you are a professional programmer who didn't get enough exposure to such topics in school or who wotlId like a refresher, or if you are a software manager who wants to guide your staff in the right direction, the material here should be of value.
　　We hope that the advice will help you to write better programs. The only prerequisite is that you have done some programming, preferably in C, C++ or Java. Of course the more experience you have, the easier it will be; nothing can take you from neophyte to expert in 21 days. Unix and Linux programmers will find some of the examples more famiIiar than will those who have used only Windows and Macintosh systems, but programmers from any environrnent shou1d discover things to make theirlives easier.
　　The presentation is organized into nine chapters, each focusing on one major aspect of programming practice.
　　Chapter 1 discusses programming style. Good style is so important to good programming that we have chosen to cover it first. Well-written programs are better than badly--written ones--they have fewer errors and are easier to debug and to modify-so it is important to think about style from the beginning. This chapter aIso introduces an important theme in good programming, the use of idioms appropriate to the language being used.
　　Algorithms and data structures, the topics of Chapter 2. are the core of the computer science curriculum and a rnajor part of programming courses. Since most readers will aIready be familiar with this material, our treatment is intended as a brief review of the handful of algorithms and data structures that show up in almost every program. More complex algorithms and data structures usual1y evolve from these building blocks, so one shouId master the basics.
　　Chapter 3 describes the design and implementation of a small program that illus-trates algorithm and data structure issues in a realistic setting. The program is implemented in five languages; cornparing the versions shows how the same data structures are handled in each, and how expressiveness and pertbrmance vary across a spectrum of languages.
　　Interfaces between users, programs, and parts of programs are fundamentaI in programming and much of the success of software is determined by how well interfaces are designed and implemented. Chapter 4 shows the evolution of a small library for parsing a widely used data format. Even though the example is small, it illustrates many of the concerns of interface design f abstraction, information hiding, resource management, and error handling.
　　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

Brian W.Kernighan：Brian W. Kernighan 贝尔实验室计算科学研究中心高级研究人员，著名的计算机科学家。他参加了UNIX系统、C语言、AWK语言和许多其他系统的开发，同时出版了许多在计算机领域具有影响的著作，包括《The Elements of Programming Style》、《The Practice of Programming》、《The UNIX Programming Environment》、《The AWK Language》、《Software Tools》等。

Rob Pike：Rob Pike（罗布·派克），目前谷歌公司最著名的软件工程师之一，曾是贝尔实验室 Unix 开发团队成员，Plan9 操作系统开发的主要领导人，Inferno 操作系统开发的主要领导人。他是缔造 Go 语言和 Limbo 语言的核心人物。

Chapter 1: Style
1.1 Names
1.2 Expressions and Statements
1.3 Consistency and Idioms
1.4 Function Macros
1.5 Magic Numbers
1.6 Comments
1.7 Why Bother
Chapter 2: Algorithms and Data Structures
2.1 Searching
2.2 Sorting
2.3 Libraries
2.4 A Java Quicksort
2.5 O-Notation
2.6 Growing Arrays
2.7 Lists
2.8 Trees
2.9 Hash Tables
2.10 Summary
Chapter 3: Design and Implementation
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