For most applications, good programmers use an organized approach to programming called structured programming. The original interpreted BASICs did not really support this kind of programming. However, PowerBASIC, with its control structures and more advanced functions and procedures, is very well suited to structured programming style.
Structured programming is based on the theory that modularization makes for better programs. Modularization means grouping statements together (making modules) that have some relation to each other. In other words, you break up your program into logical functional sections. This makes it easier to write, debug, and understand the program.
Ideally, modules should be no more than a page long. This seemingly arbitrary constraint makes it easier to absorb the entire module at a glance. It is easier to understand a series of ten single-page modules than it is a single ten-page program.
For some projects, after this initial breakup, you're ready to write the program. More complicated problems might require you to break the modules into subsidiary pieces. This process continues until you have refined the material enough so that you can write the code that corresponds to your ideas. This entire process is often described in books as "top-down design", since you start with a general description and work toward a more specific one.
Once you have the logical organization, you can start to design the overall structure of your program. For short, simple programs, these steps may only take a few minutes. For complex programs, it could take months.
To summarize the steps of structured programming (also known as 'top-down programming' or 'top-down design'):
1. Plan your program on paper. Ask yourself the following questions:
a. What is the overall purpose of the program?
b. What kind of input will it need?
c. How will it process that input?
d. What kind of output will the program produce? To where (screen, printer, disk)?
e. How should the input and output look?
f. How can the program be broken up into discrete processes (modules?)
g. How will those modules fit into the main program, and how will they communicate?
h. Can those modules be broken up into even smaller functional segments?
2. Next, write your main program. Don't worry about writing the individual modules that you separated out earlier. Instead, write stubs: Dummy statements that allow the main program to continue. This allows you to test the logic of your main program.
3. Finally (and this step will actually be several steps), write the modules one at a time. Test and debug each module thoroughly before proceeding to the next. If you've broken your module into even smaller processes, write the code for those processes first, test and debug each process, and then put them together to build your module.
See Also