This chapter is from the book
This chapter is from the book
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.