读书摘要－The practice of programming

迷南。 2022-08-26 04:54 3阅读 0赞

**The practice of programming**

**simplicity**, **clarity** and **generality** form the bedrock of good software.

**Chp 1 Style**

The purpose of style is to make the code **easy to read** for yourself and others,  
  
  
**1.1 Names**  
  
A name should be **informative**, **concise**, **memorable**, and **pronounceable** if possible.  
  
Much information comes from context and scope; the broader the scope of a variable, the more information should be conveyed by its name.  
  
Use descriptive names for globals, short names for locals.  
  
Programmers are often encouraged to use long variable names regardless of context.That is a mistake: **clarity is often achieved through brevity.**  
  
The longer the program, the more important is the choice of good, descriptive, systematic names  
  
Function names should be based on **active verbs**, perhaps followed by nouns  
  
Functions that return a boolean value should be named so that the return value is unambiguous.  
  
  
**1.2 Expressions and Statements**  
  
Write expressions as you might speak them aloud. Conditional expressions that include negations are always hard to understand.  
  
  
**1.3 Consistency and Idioms**  
  
**Specific style is much less important than its consistent application**. Pick one style, preferably ours, use it consistently, and don't waste time arguing.  
  
The program's consistency is more important than your own, because it makes life easier for those who follow.  
  
A central part of learning any language is developing a familiarity with its idioms.  
  
  
**1.5 Magic Numbers**  
  
As a guideline, any number other than 0 or 1 is likely to be magic and should have a name of its own  
  
  
**1.6 Comments**  
  
Comments are meant to help the reader of a program. They do not help by saying things the code already plainly says, or by contradicting the code, or by distracting the reader with elaborate typographical displays.  
  
Comments shouldn't report self-evident information.  
  
Global variables have a tendency to crop up intermittently throughout a program; a comment serves as a reminder to be referred to as needed.  
  
When you change code, make sure the commentsare still accurate.  
  
**Good code needs fewer comments than bad code.**  
  
  
**1.7 Why Bother?**  
  
The key observation is that good style should be a matter of habit.  
  
If you think about style as you write code originally, and if you take the time to revise and improve it, you will develop good habits.

**Chp 2 Algorithms and Data Structures**

Even within an intricate program like a compiler or a web browser, most of the data structures are arrays, lists, trees, and hash tables.

**Chp3 Design and Implementation**

As the quotation from Brooks's classic book suggests, **the design of the data structures is the central decision** in the creation of a program.Once the data structures are laid out, the algorithms tend to fall into place, and the coding is comparatively easy.  
  
 **The design of a program is rooted in the layout of its data. The data structures don't define every detail, but they do shape the overall solution.**  
  
This point of view is oversimplified but not misleading.  
  
As a rule, try to handle irregularities and exceptions and special cases in data.Code is harder to get right so the control flow should be as simple and regular as possible.  
  
The great strengths of C are that it gives the programmer complete control over implementation, and programs written in it tend to be fast. The cost, however, is that the C programmer must do more of the work, allocating and reclaiming memory, creating hash tables and linked lists, and the like. **C is a razor-sharp tool**, with which one can create an elegant and efficient program or a bloody mess.  
  
Less clear, however, is how to assess the loss of control and insight when the pile of system-supplied code gets so big that one no longer knows what's going on underneath. **This is the case with the STL version**; its performance is unpredictable and there is no easy way to address that.

**Chp 4 Interfaces**

It's not usually until you've built and used a version of the program that you understand the issues well enough to get the design right.  
  
As a principle, **library routines should not just die when an error occurs**; error status should be returned to the caller for appropriate action.  
  
Expansion of size and complexity is a typical result of moving from prototype to production.  
  
  
**4.5 Interface Principles**  
  
**Hide implementation details  
  
Choose a small orthogonal set of primitives.**  
  
Having lots of functions may make the library easier to use-whatever one needs is there for the taking. But a large interface is harder to write and maintain, and sheer size may make it hard to learn and use as well.  
  
In the interest of convenience, some interfaces provide multiple ways of doing the same thing, **a tendency that should be resisted**.  
  
**Narrow interfaces are to be preferred to wide ones**, at least until one has strong evidence that more functions are needed.  
  
  
 **Don't reach behind the user's back**  
  
 **Do the same thing the same way everywhere.**  
  
The basic strxxx functions in the C library are easy to use without documentation because they all behave about the same: data flows from right to left, the same direction as in an assignment statement, and they all return the resulting string  
  
  
**4.6 Resource Management**  
  
 **Free a resource in the same layer that allocated it.**  
  
To avoid problems, it is necessary to write code that is **reentrant**  
  
 **Detect errors at a low level, handle them at a high level.**  
  
 **In most cases, the caller should determine how to handle an error, not the callee.**  
  
**Use exceptions only for exceptional situations.**

**Chp 5 Debugging**

**5.1 Debuggers**  
  
As a personal choice, we **tend not to use debuggers** beyond getting a stack trace or the value of a variable or two.  
  
Debuggers can be arcane and difficult programs,and especially for beginners may provide more confusion than help  
  
  
**5.2 Good Clues, Easy Bugs**  
  
Debugging involves **backwards reasoning**, like solving murder mysteries.  
  
 **Look for familiar patterns  
  
Examine the most recent change  
  
Debug it now, not later  
  
Get a stack trace:**The source line number of the failure, often part of a stack trace, is the most useful single piece of debugging information  
  
**Read before typing:** Resist the urge to start typing; thinking is a worthwhile alternative  
  
 **Explain your code to someone else**  
  
  
**5.3 No Clues, Hard Bugs**  
  
 **Make the bug reproducible**  
  
 **Divide and conquer**  
  
 **Study the numerology of failures**  
  
 **Display output to localize your search.**  
  
 **Write self-checking code**  
  
 **Write a logfile**  
  
 **Draw a picture**  
  
 **Use tools**  
  
 **Keep records.  
  
  
5.4 Last Resorts**  
  
 These "**mental model**" bugs are among the hardest to find; the mechanical aid of debugger is invaluable.  
  
 A debugger is a help, since it forces you to go in a different direction, to follow what the program is doing, not what you think it is doing  
  
  
**5.5 Non-reproducible Bugs**  
  
The very fact that the behavior is nondeterministic is itself information, however; it means that the error is not likely to be a flaw in your algorithm but that in some way your code is using information that changes each time the program runs.  
  
  
**5.8 Summary**  
  
Once a bug has been seen, the first thing to do is to **think hard about the clues it presents**.  
  
If there aren't good clues, hard thinking is still the best first step, to be followed by systematic attempts to narrow down the location of the problem.

**Chp 6 Testing**

Edsger Dijkstra made the famous observation that **testing can demonstrate the presence of bugs, but not their absence.**  
  
One way to write bug-free code is to generate it by a program. If some programming task is understood so well that writing the code seems mechanical. then it should be mechanized.  
  
  
**6.1 Test as You Write the Code**  
  
**Test code at its boundaries**  
  
The idea is that **most bugs occur at boundaries** .If a piece of code is going to fail, it will likely fail at a boundary. Conversely, if it works at its boundaries, it's likely to work elsewhere too.  
  
 **Test pre- and post-conditions**  
  
**Use assertions**  
  
Assertions are particularly helpful for validating properties of interfaces because they draw attention to inconsistencies between caller and callee and may even indicate who's at fault.  
  
 **Program defensively**  
  
**Check error returns**  
  
  
**6.2 Systematic Testing**  
  
 **Test incrementally**  
  
 **Test simple parts first**  
  
 **Know what output to expect**  
  
 **Compare independent implementations.**  
  
 **Measure test coverage**  
  
 **Complete coverage is often quite difficult to achieve**  
  
  
**6.3 Test Automation**  
  
**Automate regression testing**  
  
The most basic form of automation is **regression testing**, which performs a sequence of tests that compare the new version of something with the previous version.  
  
It's easy to overlook the possibility that the fix broke something else.  
  
 **Create self-contained tests.**  
  
What should you do when you discover an error? If it was not found by an existing test, create a new test that does uncover the problen~and verify the test by running it with the broken version of the code  
  
Keep a record of bugs, changes, and fixes; it will help you identify old problems and fix new ones  
  
  
**6.5 Stress Tests**  
  
Higher volume of machine-generated input in itself tends to break things because very large inputs cause overflow of input buffers, arrays, and counters. and are effective at finding unchecked fixed-size storage within a program.  
  
Some testing is based on explicitly malicious inputs.  
  
Any routine that might receive values from outside the program, directly or indirectly, **should validate its input values before using them**.  
  
  
**6.6 Tips for Testing**  
  
**Test on multiple machines, compilers, and operating systems**. Each combination potentially reveals errors that won't be seen on others  
  
  
**6.7 Who Does the Testing?**  
  
It is important to test your own code: don't assumethat some testing organization or user will find things for you  
  
The reason for testing is to find bugs, not to declare the program working.  
  
It's hard to test interactive programs, especially if they involve mouse input.  
  
Interactive programs should be controllable from scripts that simulate user behaviors so they can be tested by programs  
  
  
**6.9 Summary**  
  
The single most important rule of testing is to **do it !**.

**Chp 7 Performance**

The first principle of optimization is **don't !**  
  
**7.1 A Bottleneck**  
  
When solving problems, it's important to ask the right question.  
  
  
**7.2 Timing and Profiling**  
  
 **Knuth's guideline** is right: a small part of the program consumes most of the run-time  
  
When a single function is so overwhelmingly the bottleneck, there are only two ways to go: improve the function to use a better algorithm, or eliminate the function altogether by rewriting the surrounding program.  
  
  
**7.3 Strategies for Speed**  
  
**Use a better algorithm or data structure.**  
  
**Enable compiler optimizations**  
  
One thing to be aware of is that the more aggressively the compiler optimizes, the more likely it is to introduce bugs into the compiled program. After enabling the optimizer, re-run your regression test suite. as you should for any other modification.  
  
**Tuning**  
  
It is typical of tuning: some things help,some things don't. and one must measure to find out which.  
  
  
**Don't optimize what doesn't matter**  
  
Optimizing public services like the spam filter or a library is almost always worthwhile; speeding up test programs is almost never worthwhile.  
  
  
**7.4 Tuning the Code**  
  
Bear in mind that good compilers will do some of these for you, and in fact you may impede their efforts by complicating the program.  
  
 **Collect common subexpressions**  
  
 **Replace expensive operations by cheap ones**  
  
 **Unroll or eliminate loops.**  
  
 **Cache frequently-used values.**  
  
 **Write a special-purpose allocator.**  
  
 **Buffer input and output**  
  
When a C program calls printf, for example, the characters are stored in a buffer but not passed to the operating system until the buffer is full or flushed explicitly. The operating system itself may in turn delay writing the data to disk.  
  
 **Handle special cases separately**  
  
 **Precompute results——trading space for time**  
  
 **Use approximate values**  
  
 **Rewrite in a lower-level language**  
  
  
**7.5 Space Efficiency**  
  
In general, it is best to **store information as text wherever feasible** rather than in some binary representation. Text is **portable**, **easy to read**, and **amenable** to processing by all kinds of tools; binary representations have none of these advantages.  
  
**7.7 Summary**  
  
By the way, it's extremely difficult to do good benchmarking, and it is not unknown for companies to tune their products to show up well on benchmarks. so **it is wise to take all benchmark results with a grain of salt**.

**Chp 8 Portability**

**8.1 Language**  
  
**Binaries don't port well, but source code does**.  
  
**Program in the mainstream.**  
  
It's hard to know just where the mainstream is, but it's easy to recognize constructions that are well outside it.  
  
By definition, all side effects and function calls must be completed at each semicolon, or when a function is called.  
  
**Bitfields are so machine-dependent that no one should use them.**  
  
  
**8.2 Headers and Libraries**  
  
Use standard libraries  
  
  
**8.3 Program Organization**  
  
There are two major approaches to portability, which we will call **union** and **intersection**.The approach we recommend is **intersection**: use only those features that exist in all target systems  
  
Union code is by design unportable.  
  
 **Avoid conditional compilation.**  
  
Conditional compilation with \#ifdef and similar preprocessor directives is **hard to manage**, because information tends to get sprinkled throughout the source.  
  
Mixing compile-time control flow (determined by \#ifdef statements) with runtimecontrol flow is much worse, since it is very **difficult to read**.  
  
The nastiest problem with conditional compilation is one we haven't mentioned: it is **almost impossible to test**  
  
  
**8.4 Isolation**  
  
**Localize system dependencies in separate files.**  
  
When different code is needed for different systems, the differences should be localized in separate files, one file for each system.  
  
 **Hide system dependencies behind interfaces**  
  
  
**8.5 Data Exchange**  
  
**Textual data** moves readily from one system to another and is the **simplest portable way** to exchange arbitrary information between systems.  
  
Good example: SMTP use **MIME encoding** for transferring binary data in mail messages  
  
**8.6 Byte Order**  
  
Still, the best solution is often to **convert information to text format**, which (except for the CRLF problem) is **completely portable.**  
  
  
**8.7 Portability and Upgrade**  
  
Change the name if you change the specification(behavior)  
  
  
**8.8 Internationalization**  
  
Unicode documents are usually translated into a byte-stream encoding called UTF-8 before being sent between programs or over a network.

**Chp 9 Notation**

**"Perhaps of all the creations of man language is the most astonishing"**  
  
The right language can make all the difference in how easy it is to write a program. This is why a practicing programmer's arsenal holds not only general purpose languages like C and its relatives, but also programmable shells, scripting languages, and lots of application-specific languages.  
  
 **9.1 Formatting Data**  
  
There is always a gap between what we want to say to the computer ("solve my problem") and what we are required to say to get a job done.  
  
The narrower this gap, the better.  
  
Good notation makes it easier to say what we want and harder to say the wrong thing by mistake  
   
Little languages are specialized notations for narrow domains.The **printf** control sequences are a good example.  
  
  
**9.3 Programmable Tools**  
  
Programmable tools often originate in little languages designed for natural expression of solutions to problems within a narrow domain  
  
  
**9.4 Interpreters, Compilers, and Virtual Machines**  
  
A virtual machine combines many of the advantages of conventional interpretation and compilation.  
  
Parsers are often written with the aid of an automatic parser generator, also called a compiler-compiler. such as yacc or bison.  
  
Virtual machines are a lovely old idea.  
  
  
**9.5 Programs that Write Programs**  
  
The most common program-writing program is a compiler that translates highlevel language into machine code.  
  
In spite of the power of program generators, and in spite of the existence of many good examples, the notion is not appreciated as much as it should be and is infrequently used by individual programmers.  
  
The large-scale version of self-documenting code is **literate programming**, which integrates a program and its documentation so one process prints it in a natural order for reading, and another arranges it in the right order for compilation.  
  
  As tasks become so focused and well understood that programming them feels almost mechanical, it may be time to create a notation that naturally expresses the tasks and a language that implements it.**Regular expression** is a good example.

**Epilogue**

**Simplicity and clarity are first and most important**