Documentation for other programmers

Documenting a program is not something you do at the end of the project; your documentation will be much more complete, and more useful to others, if you record information about the program as you structure and code it. Include any information that might be useful to someone else who must work with your program.

The reason you record this information is so that people who maintain your program know why you chose certain commands, options, call structures, and command codes. For example, if the DBA were considering reorganizing the database in some way, information about why your program accesses the data the way it does would be helpful.

Information you can include for other programmers includes:

• Flowcharts and pseudocode for the program
• Comments about the program from code inspections
• A written description of the program flow
• Information about why you chose the call sequence you did, such as:
  • Did you test the call sequence using DFSDDLT0?
  • In cases where more than one combination of calls would have had the same results, why did you choose the sequence you did?
  • What was the other sequence? Did you test it using DFSDDLT0?
• Any problems you encountered in structuring or coding the program
• Any problems you had when you tested the program
• Warnings about what should not be changed in the program

All this information relates to structuring and coding the program. In addition, you should include the documentation for end users with the documentation for programmers.

Ultimately, you must determine the level of detail necessary and the most suitable form for documenting the program. These documentation guidelines are provided as suggestions.