"A clean design is more easily modified as requirements change or as more is learned about what parts of the code consume significant amounts of execution time. A 'clever' design that fails to work or to run fast enough can often be salvaged only at great cost. Efficiency does not have to be sacrificed in the interest of writing readable code - rather, writing readable code is often the only way to ensure efficient programs that are also easy to maintain and modify." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"A computer program is shaped by its data representation and the statements that determine its flow of control. These define the structure of a program. There is no sharp distinction between expression and organization; it is more a question of scope." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"A powerful tool for reducing apparent complexity is recursion. In a recursive procedure, the method of solution is defined in terms of itself. That is, each part of the routine handles only a small piece of the strategy, then calls the other parts of the routine as needed to handle the rest. The trick is to reduce each hard case to one that is handled simply elsewhere." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Choosing a better data structure is often an art, which we cannot teach. Often you must write a preliminary draft of the code before you can determine what changes in the data structure will help simplify control. [...] Choose a data representation that makes the program simple." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don’t comment bad code - rewrite it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't compare floating point numbers just for equality." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't diddle code to make it faster - find a better algorithm." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't just echo the code with comments make every comment count." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't patch bad code - rewrite it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't sacrifice clarity for small gains in 'efficiency'." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't strain to re-use code; reorganize instead." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Don't use conditional branches as a substitute for a logical expression." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Format a program to help the reader understand it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"'Good programmers' are those who already have learned a set of rules that ensures good style; many of them will read this book and see no reason to change. If you are still learning to be a 'good programmer', however, then perhaps some of what we consider good style will have rubbed off in the reading." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Good programming cannot be taught by preaching generalities. The way to learn to program well is by seeing, over and over, how real programs can be improved by the application of a few principles of good practice and a little common sense. Practice in critical reading leads to skill in rewriting, which in turn leads to better writing." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Indent to show the logical structure of a program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Instrument your programs. Measure before making 'efficiency' changes." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"It is a good rule of thumb that a program should read from top to bottom in the order that it will be executed; if this is not true, watch out for the bugs that often accompany poor structure. Make your programs read from top to bottom." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Jumping around unnecessarily in a computer program has proved to be a fruitful source of errors, and usually indicates that the programmer is not entirely in control of the code." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Let the data structure the program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Let your compiler do the simple optimizations." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make it right before you make it faster.[...] Keep it right when you make it faster. [...] Make it clear before you make it faster. [...] Keep it simple to make it faster."
"Make sure every module hides something." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make sure special cases are truly special." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make the coupling between modules visible." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make input easy to prepare and output self-explanatory. [...] Use uniform input formats. [...] Make input easy to proofread. [...] Use self-identifying input. Allow defaults. Echo both on output. [...] Localize input and output in subroutines." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make sure all variables are initialized before use." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Make sure comments and code agree." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Most programs are too big to be comprehended as a single chunk. They must be divided into smaller pieces that can be conquered separately. That is the only way to write them reliably; it is the only way to read and understand them. [...] When a program is not broken up into small enough pieces, the larger modules often fail to deliver on these promises. They try to do too much, or too many different things, and hence are difficult to maintain and are too specialized for general use." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"[...] no program is ever perfect; there is always room for improvement. Of course, it is foolish to polish a program beyond the point of diminishing returns, but most programmers do too little revision; they are satisfied too early. Don't stop with your first draft." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Notice that even the data is commented. One of the most effective ways to document a program is simply to describe the data layout in detail. If you can specify for each important variable what values it can assume and how it gets changed, you have gone a long way to describing the program. [...] Document your data layouts." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Program defensively." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Program organization, deciding what gets done where, is often given insufficient consideration. This can be true even when the format of input or output data strongly suggests the most convenient order of processing. Failure to heed such suggestions leads to code that is hard to relate to the problem being solved, and hence likely to contain mistakes." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Programmers have a strong tendency to underrate the importance of good style. Eternally optimistic, we all like to think that once we throw a piece of code together, however haphazardly, it will work properly the first time and ever after. Why waste time cleaning up something that is almost certain to be correct? Besides, it probably will be used for only a few weeks." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Programs are not used once and discarded, nor are they run forever without change. They evolve. The new version of the integration program has a greater likelihood of surviving changes later without acquiring bugs. It assists instead of intimidating those who must maintain it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Recursion represents no saving of time or storage. Somewhere in the computer must be maintained a list of all the places a recursive routine is called, so the program can eventually find its way back. But the storage for that list is shared among many different uses. More important, it is managed automatically; many of the burdens of storage management and control flow are placed on the compiler, not on the programmer. And since bookkeeping details are hidden, the program can be much easier to understand. Learning to think recursively takes some effort, but it is repaid with smaller and simpler programs." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Repeated patterns of code catch the eye when scanning listings. Since the computer is a tool for handling repetitious operations, we should be alerted by such patterns to look for oversights - why didn't the programmer let the computer do the repeating?" (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Say what you mean, simply and directly." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"The best documentation for a computer program is a clean structure. It also helps if the code is well formatted, with good mnemonic identifiers and labels (if any are needed), and a smattering of enlightening comments. Flowcharts and program descriptions are of secondary importance; the only reliable documentation of a computer program is the code itself. The reason is simple -whenever there are multiple representations of a program, the chance for discrepancy exists. If the code is in error, artistic flowcharts and detailed comments are to no avail. Only by reading the code can the programmer know for sure what the program does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Test input for validity and plausibility. [...] Make sure input cannot violate the limits of the program. [...] Identify bad input; recover if possible. [...] Test programs at their boundary values." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"The fewer temporary variables in a program, the less chance there is that one will not be properly initialized, or that one will be altered unexpectedly before it is used. 'Temporary' is a dirty word in programming - it suggests that a variable can be used with less thought than a 'normal' (permanent?) one, and it encourages the use of one variable for several unrelated calculations. Both are dangerous practices." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"The general rule is: after you make a decision, do something. Don't just go somewhere or make another decision. If you follow each decision by the action that goes with it, you can see at a glance what each decision implies. Follow each decision as closely as possible with its associated action." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Use IF-ELSE to emphasize that only one of two actions is to be performed." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Use recursive procedures for recursively-defined data structures." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Use the good features of a language; avoid the bad ones." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Use variable names that mean something." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Watch out for off-by-one errors. A common cause of off-by-one errors is an incorrect test, for example using 'greater than' when 'greater than or equal to' is actually needed. This program is a binary search routine, which looks for a particular element in a table by halving the interval in which the element might lie, until it ultimately either finds it, or deduces that it isn't present." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"When the operation to be done is more complex, write a separate subroutine or function. The ease of later comprehending, debugging, and changing the program will more than compensate for any overhead caused by adding the extra modules." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Write and test a big program in small pieces." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Writing a computer program eventually boils down to writing a sequence of statements in the language at hand. How each of those statements is expressed determines in large measure the intelligibility of the whole; no amount of commenting, formatting, or supplementary documentation can entirely replace well expressed statements. After all, they determine what the program actually does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"Controlling complexity is the essence of computer programming." (Brian W Kernighan, "Software Tools", 1976)
"Mechanical rules are never a substitute for clarity of thought." (Brian W Kernighan, "Software Tools", 1976)
"First is the sheer joy of making things. Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful." (Brian W Kernighan, "Hello, World! Opinion columns from the Daily Princetonian", 2011)
"A computer is a general-purpose machine. It takes its instructions from memory, and one can change the computation it performs by putting different instructions in the memory. Instructions and data are indistinguishable except by context; one person’s instructions are another person’s data." (Brian W Kernighan, "Understanding the Digital World", 2017)
"A standard is a precise and detailed description of how some artifact is built or is supposed to work." (Brian W Kernighan, "Understanding the Digital World", 2017)
"[...] algorithms, which are abstract or idealized process descriptions that ignore details and practicalities. An algorithm is a precise and unambiguous recipe. It’s expressed in terms of a fixed set of basic operations whose meanings are completely known and specified. It spells out a sequence of steps using those operations, with all possible situations covered, and it’s guaranteed to stop eventually." (Brian W Kernighan, "Understanding the Digital World", 2017)
"An algorithm is the computer science version of a careful, precise, unambiguous recipe or tax form, a sequence of steps that is guaranteed to compute a result correctly." (Brian W Kernighan, "Understanding the Digital World", 2017)
"By contrast, a program is anything but abstract - it’s a concrete statement of every step that a real computer must perform to accomplish a task. The distinction between an algorithm and a program is like the difference between a blueprint and a building; one is an idealization and the other is the real thing." (Brian W Kernighan, "Understanding the Digital World", 2017)
"Cryptography, the art of 'secret writing', is in many ways our best defense against the attacks noted above and those yet to come. Properly done, cryptography is wonderfully flexible and powerful. Unfortunately good cryptography is also difficult and subtle, and all too often defeated by human error." (Brian W Kernighan, "Understanding the Digital World", 2017)
"Programming in the real world tends to happen on a large scale. The strategy is similar to what one might use to write a book or undertake any other big project: figure out what to do, starting with a broad specification that is broken into smaller and smaller pieces, then work on the pieces separately while making sure that they hang together. In programming, pieces tend to be of a size such that one person can write the precise computational steps in some programming language. Ensuring that the pieces written by different programmers work together is challenging, and failing to get this right is a major source of errors." (Brian W Kernighan, "Understanding the Digital World", 2017)
"Sadly, no substantial program works the first time; life is too complicated and programs reflect that complexity. Programming requires perfect attention to detail, something that few people can achieve. Thus all programs of any size will have errors, that is, they will do the wrong thing or produce the wrong answer under some circumstances. Those flaws are called bugs [...]" (Brian W Kernighan, "Understanding the Digital World", 2017)
"The good news is that a computer is a general-purpose machine, capable of performing any computation. Although it only has a few kinds of instructions to work with, it can do them very fast, and it can largely control its own operation. The bad news is that it doesn’t do anything itself unless someone tells it what to do, in excruciating detail. A computer is the ultimate sorcerer’s apprentice, able to follow instructions tirelessly and without error, but requiring painstaking accuracy in the specification of what to do." (Brian W Kernighan, "Understanding the Digital World", 2017)
"There aren’t enough programmers in the world to do the amount of programming involved in making computers do everything we want or need." (Brian W Kernighan, "Understanding the Digital World", 2017)
"Why should anyone know or care about binary numbers? One reason is that working with numbers in an unfamiliar base is an example of quantitative reasoning that might even improve understanding of how numbers work in good old base ten. Beyond that, it’s also important because the number of bits is usually related in some way to how much space, time or complexity is involved. And fundamentally, computers are worth understanding, and binary is central to their operation." (Brian W Kernighan, "Understanding the Digital World", 2017)
"Do what you think is interesting, do something that you think is fun and worthwhile, because otherwise you won’t do it well anyway." (Brian W Kernighan [interview])
"Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed 'Never mind, I see what's wrong. Sorry to bother you.' This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor." (Brian W Kernighan)
No comments:
Post a Comment