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 building blocks, of large programs.

• Modularize. Use subroutines
• Make the coupling between modules visibles
• Each module should do one thing well
• Make sure every module hides something
• Let the data structure the program
• Don’t patch bad code – rewrite it 
• Write and test a big program in small pieces
• Use recursive procedures for recursively-defined data structures

The discipline of breaking a large job into appropriate small pieces is often called “structured design” and sometimes “composite design.” Whatever you choose to call it, that discipline is necessary. To summarize some of the points made in this chapter about program structure, 

(1) The only way to write and maintain a big program is as a set of small functions, subroutines, or procedures. No module should have to know much about the total problem, nor deal with more than a handful of immediate neighbors. 

(2) Each module should deal with but one aspect of the solution, for otherwise it will become too big and too complicated. If a module does precisely one job, then it will not become a tangle of pieces lumped arbitrarily, nor will it be simply a displaced fragment of some other module. 
(3) A module should hide from its fellows the details of how it performs its task, for otl-erwise one module cannot be changed independently of others.