This chapter is from the book

Summary

A builder doesn't build a house before designing it, and a programmer
should not write a program without designing it either. Too often, programmers
rush to the keyboard without thinking through the logic. A badly designed
program results in lots of bugs and maintenance. This hour described how to
ensure that your program design matches the design that the user wants. After
you complete the output definition, you can organize the program's logic
using top-down design, flowcharts, and pseudocode.

The next hour focuses on training you in your first computer language,
Liberty BASIC.

Q&A

Q At what point in the top-down design should I begin to add
details?

A Put off the details as long as possible. If you are designing a
program to produce sales reports, you would not enter the printing of the final
report total until you had completed all the other report design tasks. The
details fall out on their own when you can no longer break a task into two or
more other tasks.

Q Once I break the top-down design into its lowest-level details,
don't I also have the pseudocode details?

A The top-down design is a tool for determining all the details
your program will need. The top-down design doesn't, however, put those
details into their logical execution order. The pseudocode dictates the
executing logic of your program and determines when things happen, the order
they happen in, and when they stop happening. The top-down design simply
determines everything that might happen in the program. Instead of pseudocode,
however, you should consider getting a RAD tool that will help you move faster
from the design to the finished, working program. Today's RAD systems are
still rather primitive, and you'll have to add much of the code
yourself.