Pseudocode Programming Process

Guidelines for using pseudocode
1. Use English-like statements that precisely describe specific operations.
2. Avoid syntactic elements from the target programming language.
3. Write pseudocode at the level of intent, rather than how the approach will be implemnet in the target language.
4. Write pseudocode at a low enough level that generating code from it will nearly automatica.
Once the pseudocode is written, you build the code around it and the pseudoccode turns into programming-language comments.

Benefits you can expect from using this style of pseudocode
1. Pseudocode makes reviews easier.
2. Pseudocode supports the idea of iterative refinement.
You start with a high level design, refine the design to pseudocode, and then refine the pseudocode to source code.
3. Pseudocode makes changes easier.
A few lines of pseudocode are easier to change than a page of code.
4. Pseudocode minimizes commenting effort.
5. Pseudocode is easier to maintain than other forms of design documentation.
With other approaches, design is separated from the code, and when one changes, the two fall out of agreement.

Design the Routine
1. Check the prerequisties.
Check to be sure that the routine is actually called for, at the very least indirectly, by the project's requirements.
2. Define the problem the routine will solve.
       The information the routine will hide
       Input to the routine
       Output from the routine
       Precondition that are guaranteed to be true.
       Post condition that the routine guarantees will be true.
3. Name the routine
4. Decide how to test the routine.
5. Think about error handling.
6. Think about efficiency.
7. Research functionality available in the standard libraries.
8. Research the algorighms and data types.
9. Write the pseudocode.
10. Think about the data.
Definitions of key data types are useful to have when you design the logic of a routine.
11. Check the pseudocode.
12. Try a few ideas in pseudocode, and keep the best.
13. Turn the pseudocode into high-level comments.
14. Fill in the code below each comment.
15. Check whether code should be further factored.