代码大全[第二版·英文珍藏版]

.3.6 amount of time to spend on upstream prerequisites
4 key construction decisions
4.1 choice of programming language
4.2 programming conventions
4.3 your location on the technology wave
4.4 selection of major construction practices
part ii creating high-quality code
5 design in construction
5.1 design challenges
5.2 key design concepts
5.3 design building blocks: heuristics
5.4 design practices
5.5 comments on popular methodologies
6 working classes
6.1 class foundations: abstract data types (adts)
6.2 good class interfaces
6.3 design and implementation issues
6.4 reasons to create a class
6.5 language-specific issues
6.6 beyond classes: packages
7 high-quality routines
7.1 valid reasons to create a routine
7.2 design at the routine level
7.3 good routine names
7.4 how long can a routine be?
7.5 how to use routine parameters
7.6 special considerations in the use of functions
7.7 macro routines and inline routines
8 defensive programming
8.1 protecting your program from invalid inputs
8.2 assertions
8.3 error-handling techniques
8.4 exceptions
8.5 barricade your program to contain the damage caused by errors
8.6 debugging aids
8.7 determining how much defensive programming to leave in production code
8.8 being defensive about defensive programming
9 the pseudocode programming process
9.1 summary of steps in building classes and routines
9.2 pseudocode for pros
9.3 constructing routines by using the ppp
9.4 alternatives to the ppp
part iii variables
10 general issues in using variables
10.1 data literacy
10.2 making variable declarations easy
10.3 guidelines for initializing variables
10.4 scope
10.5 persistence
10.6 binding time
10.7 relationship between data types and control structures
10.8 using each variable for exactly one purpose
11 the power of variable names
11.1 considerations in choosing good names
11.2 naming specific types of data
11.3 the power of naming conventions
11.4 informal naming conventions
11.5 standardized prefixes
11.6 creating short names that are readable
11.7 kinds of names to avoid
12 fundamental data types
12.1 numbers in general
12.2 integers
12.3 floating-point numbers
12.4 characters and strings
12.5 boolean variables
12.6 enumerated types
12.7 named constants
12.8 arrays
12.9 creating your own types (type aliasing)
13 unusual data types
13.1 structures
13.2 pointers
13.3 global data
part iv statements
14 organizing straight-line code
14.1 statements that must be in a specific order
14.2 statements whose order doesn't matter
15 using conditionals
15.1 if statements
15.2 case statements
16 controlling loops
16.1 selecting the kind of loop
16.2 controlling the loop
16.3 creating loops easily--from the inside out
16.4 correspondence between loops and arrays
17 unusual control structures
17.1 multiple returns from a routine
17.2 recursion
17.3 goto
17.4 perspective on unusual control structures
18 table-driven methods..
18.1 general considerations in using table-driven methods
18.2 direct access tables
18.3 indexed access tables
18.4 stair-step access tables
18.5 other examples of table lookups
19 general control issues
19.1 boolean expressions
19.2 compound statements (blocks)
19.3 null statements.
19.4 taming dangerously deep nesting
19.5 a programming foundation: structured programming
19.6 control structures and complexity
part v code improvements
20 the software-quality landscape
20.1 characteristics of software quality
20.2 techniques for improving software quality
20.3 relative effectiveness of quality techniques
20.4 when to do quality assurance
20.5 the general principle of software quality
21 collaborative construction
21.1 overview of collaborative development practices
21.2 pair programming
21.3 formal inspections
21.4 other kinds of collaborative development practices
22 developer testing
22.1 role of developer testing in software quality
22.2 recommended approach to developer testing
22.3 bag of testing tricks
22.4 typical errors
22.5 test-support tools
22.6 improving your testing
22.7 keeping test records
23 debugging
23.1 overview of debugging issues
23.2 finding a defect
23.3 fixing a defect
23.4 psychological considerations in debugging
23.5 debugging tools--obvious and not-so-obvious
24 refactoring
24.1 kinds of software evolution
24.2 introduction to refactoring
24.3 specific refactorings
24.4 refactoring safely
24.5 refactoring strategies
25 code-tuning strategies
25.1 performance overview
25.2 introduction to code tuning
25.3 kinds of fat and molasses
25.4 measurement
25.5 iteration
25.6 summary of the approach to code tuning
26 code-tuning techniques
26.1 logic
26.2 loops
26.3 data transformations
26.4 expressions
26.5 routines
26.6 recoding in a low-level language
26.7 the more things change, the more they stay the same
part vi system considerations
27 how program size affects construction
27.1 communication and size
27.2 range of project sizes
27.3 effect of project size on errors
27.4 effect of project size on productivity
27.5 effect of project size on development activities
28 managing construction
28.1 encouraging good coding
28.2 configuration management
28.3 estimating a construction schedule
28.4 measurement
28.5 treating programmers as people
28.6 managing your manager
29 integration
29.1 importance of the integration approach
29.2 integration frequency--phased or incremental?
29.3 incremental integration strategies
29.4 daily build and smoke test
30 programming tools
30.1 design tools
30.2 source-code tools
30.3 executable-code tools
30.4 tool-oriented environments
30.5 building your own programming tools
30.6 tool fantasyland
part vii software craftsmanship
31 layout and style
31.1 layout fundamentals
31.2 layout techniques
31.3 layout styles
31.4 laying out control structures
31.5 laying out individual statements
31.6 laying out comments
31.7 laying out routines
31.8 laying out classes
32 self-documenting code
32.1 external documentation
32.2 programming style as documentation
32.3 to comment or not to comment
32.4 keys to effective comments
32.5 commenting techniques
32.6 ieee standards
33 personal character
33.1 isn't personal character off the topic?
33.2 intelligence and humility
33.3 curiosity
33.4 intellectual honesty
33.5 communication and cooperation
33.6 creativity and discipline
33.7 laziness
33.8 characteristics that don't matter as much as you might think
33.9 habits
34 themes in software craftsmanship
34.1 conquer complexity
34.2 pick your process
34.3 write programs for people first, computers second
34.4 program into your language, not in it
34.5 focus your attention with the help of conventions
34.6 program in terms of the problem domair
34.7 watch for falling rocks
34.8 iterate, repeatedly, again and again
34.9 thou shalt rend software and religion asunder
35 where to find more information
35.1 information about software construction
35.2 topics beyond construction
35.3 periodicals
35.4 a software developer's reading plan
35.5 joining a professional organization
bibliography
index...

.　　这本书英文版的配套网站是http：／／www．cc2e．com，书中左侧出现的类似cc2e．com／1234的标志的含义请参阅前言中的说明。本书中文版的配套网站是http：／／www．cc2e．com．cn，凡是书中出现的cc2e．com／1234均可对应访问cc2e．com．cn／1234。...
　　译 者
　　2006年2月初
　　

.　　Complete software-construction reference This handbook discusses general aspects of construction such as software quality and ways to think about programming. It gets into nitty-gritty construction details such as steps in building classes, ins and outs of using data and control structures, debugging, refactoring, and code-tuning techniques and strategies. You don't need to read it cover to cover to learn about these topics. The book is designed to make it easy to find the specific information that interests you.
　　Ready-to-use checklists This book includes dozens of checklists you can use to assess your software architecture, design approach, class and routine quality, variable names, control structures, layout, test cases, and much more. ..
　　State-of-the-art information This handbook describes some of the most up-to-date techniques available, many of which have not yet made it into common use. Because this book draws from both practice and research, the techniques it describes will remain useful for years.
　　Larger perspective on software development This book will give you a chance to rise above the fray of day-to-day fire fighting and figure out what works and what doesn't. Few practicing programmers have the time to read through the hundreds of books and journal articles that have been distilled into this handbook. The research and realworld experience gathered into this handbook will inform and stimulate your thinking about your projects, enabling you to take strategic action so that you don't have to fight the same battles again and again.
　　Absence of hype Some software books contain 1 gram of insight swathed in 10 grams of hype. This book presents balanced discussions of each technique's strengths and weaknesses. You know the demands of your particular project better than anyone else. This book provides the objective information you need to make good decisions about your specific circumstances.
　　Concepts applicable to most common languages This book describes techniques you can use to get the most out of whatever language you're using, whether it's C++, C#, Java, Microsoft Visual Basic, or other similar languages.
　　Numerous code examples The book contains almost 500 examples of good and bad code. I've included so many examples because, personally, I learn best from examples. I think other programmers learn best that way too.
　　The examples are in multiple languages because mastering more than one language is often a watershed in the career of a professional programmer. Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity.
　　To make the multiple-language burden as light as possible, I've avoided esoteric language features except where they're specifically discussed. You don't need to understand every nuance of the code fragments to understand the points they're making. If you focus on the point being illustrated, you'll find that you can read the code regardless of the language. I've tried to make your job even easier by annotating the significant parts of the examples.
　　Access to other sources of information This book collects much of the available information on software construction, but it's hardly the last word. Throughout the chapters, "Additional Resources" sections describe other books and articles you can read as you pursue the topics you find most interesting.
　　Book website Updated checklists, books, magazine articles, Web links, and other content are provided on a companion website at cc2e. com. To access information related to Code Complete, 2d ed., enter cc2e. com/ followed by a four-digit code, an example of which is shown here in the left margin. These website references appear throughout the book.
　　Why This Handbook Was Written
　　The need for development handbooks that capture knowledge about effective development practices is well recognized in the software-engineering community. A report of the Computer Science and Technology Board stated that the biggest gains in software-development quality and productivity will come from codifying, unifying, and distributing existing knowledge about effective software-development practices (CSTB 1990, McConnel11997a). The board concluded that the strategy for spreading that knowledge should be built on the concept of software-engineering handbooks.
　　The Topic of Construction Has Been Neglected
　　At one time, software development and coding were thought to be one and the same. But as distinct activities in the software-development life cycle have been identified, some of the best minds in the field have spent their time analyzing and debating methods of project management, requirements, design, and testing. The rush to study these newly identified areas has left code construction as the ignorant cousin of software development.
　　Discussions about construction have also been hobbled by the suggestion that treating construction as a distinct software development activity implies that construction must also be treated as a distinct phase. In reality, software activities and phases don't have to be set up in any particular relationship to each other, and it's useful to discuss the activity of construction regardless of whether other software activities are performed in phases, in iterations, or in some other way.
　　Construction Is Important
　　Another reason construction has been neglected by researchers and writers is the mistaken idea that, compared to other software-development activities, construction is a relatively mechanical process that presents little opportunity for improvement. Nothing could be further from the truth.
　　Code construction typically makes up about 65 percent of the effort on small projects and 50 percent on medium projects. Construction accounts for about 75 percent of the errors on small projects and 50 to 75 percent on medium and large projects. Any activity that accounts for 50 to 75 percent of the errors presents a clear opportunity for improvement. (Chapter 27 contains more details on these statistics.)
　　Some commentators have pointed out that although construction errors account for a high percentage of total errors, construction errors tend to be less expensive to fix than those caused by requirements and architecture, the suggestion being that they are therefore less important. The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high. Researchers have found that small-scale coding errors account for some of the most expensive software errors of all time, with costs running into hundreds of millions of dollars (Weinberg 1983, SEN 1990). An inexpensive cost to fix obviously does not imply that fixing them should be a low priority.
　　The irony of the shift in focus away from construction is that construction is the only activity that's guaranteed to be done. Requirements can be assumed rather than developed; architecture can be shortchanged rather than designed; and testing can be abbreviated or skipped rather than fully planned and executed. But if there's going to be a program, there has to be construction, and that makes construction a uniquely fruitful area in which to improve development practices.
　　No Comparable Book Is Available
　　In light of construction's obvious importance, I was sure when I conceived this book that someone else would already have written a book on effective construction practices. The need for a book about how to program effectively seemed obvious. But I found that only a few books had been written about construction and then only on parts of the topic. Some had been written 15 years or more earlier and employed relatively esoteric languages such as ALGOL, PL/I, Ratfor, and Smalltalk. Some were written by professors who were not working on production code. The professors wrote about techniques that worked for student projects, but they often had little idea of how the techniques would play out in full-scale development environments. Still other books trumpeted the authors' newest favorite methodologies but ignored the huge repository of mature practices that have proven their effectweness over time.
　　In short, I couldn't find any book that had even attempted to capture the body of practical techniques avafiable from professional experience, industry research, and academic work. The discussion needed to be brought up to date for current programming languages, object-oriented programming, and leading-edge development practices. It seemed dear that a book about programming needed to be written by someone who was knowledgeable about the theoretical state of the art but who was also building enough production code to appreciate the state of the practice. I conceived this book as a full discussion of code construction-from one programmer to another. ...