Chapter 5: Input and output

• Test input for validity and plausibility
• Make sure input cannot violate the limits of the program
• Terminate input by end-of-file or maker, not by count
• Identify bad input, recover if possible
• Treat and of file conditions in a uniform manner
• Make input easy to prepare and output self-explanatory
• Use uniform input formats
• Make input easy to proofread
• Use free-form input when possible
• Use self-identifying input. Allow defaults. Echo bot on output
• Localize input and output in subroutines

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 to use correctly. Ask yourself: Will it defend itself against the stupidity and ignorance of its users (including myself)? Would I want to have to use it myself? 

To summarize the major principles discussed in this chapter: 

(1) Check input data for validity and plausibility. 

(2) Make sure that data does not violate limitations of the program. (“Garbage in, garbage out” is not a law of nature, but a commentary on how well principles (1) and (2) are followed in practice.)

(3) Read input until end-of-file or marker, not by count. 

(4) Identify input errors and recover if possible. Do not stop on the first error. Do not simply ignore errors. 

(5) Use mnemonic input and output. Make input easy to prepare (and easy to prepare correctly). Echo the input and any defaults onto the output; make output self-explanatory.

(6) Localize 1/0 instead of spreading it all over the program. Hide the details of end of file, buffering, etc., in functions. 

(7) Make sure that program structure reflects the data the program processes.