When the book saw the lights, programming wasn’t as important as today. But, some of the ideas around the style of writing are a worth to notice and to know it. For that reason reading the book written by Brian Kernighan and P. J. Plauger are a constant invitation to revisit the way we code,

Epilogue There are many good books on languages, algorithms and numerical methods available to those who want to learn programming in greater depth. Our goal was not to teach languages or algorithms, but to teach you to program well.  Programmers have a strong tendency to underrate the importance of good style. Eternally optimistic, we all

Chapter 8: Documentation 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

Chapter 7: Efficiency and instrumentation Machines have become increasingly cheap compared to people; any discussion of computer efficiency that fails to take this into account is shortsighted. “Efficiency” involves the reduction of overall cost – not just machine time over the life of the program, but also time spent by the programmer and by the

Chapter 6: Common Blunders A major concern of programming is making sure that a program can defend against bad data. But even with correct data, there is no guarantee that a program will work. In this chapter we will discuss other aspects of making software reliable. Let us summarize the main lessons of this chapter.

Chapter 5: Input and output Input/output is the interface between a program and its environment. Two rules govern all I/O programming: NEVER TRUST ANY DATA, and REMEMBER THE USER. This requires that a program be as foolproof as is reasonably possible, so that it behaves intelligently even when used incorrectly, and that it be easy

Chapter 4: Program Structure 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.  Subroutines, functions, and procedures are the “modules,” or