IBM i General Design Standards › Design Standards for Programs › Program Modularization
Program Modularization
The following practical rules can be applied to the modularization of programs:
- Do not combine unrelated or weakly related functions onto the same panels. For example, one panel, one task is easier to understand, program, and maintain.
- Place commonly required functions into standard type subprograms; for example code validation, enquiry functions. This allows faster, less error-prone coding.
- Both capability checking (whether a user is allowed to carry out a task) and entity manipulation (for example, the creation and deletion of records representing entities) are generally best modularized into standard functions.
- Provide a single entry and exit point.
- Do not place repeatedly required subroutines in programs using automatic storage allocation (PASA), for example, CL programs. The repeated re-initiation overhead is very high. Instead, use programs written in a language employing static storage allocation (PSSA), for example, RPG III, and do not close down the program when exiting from the programs.
- Alternatively, it may be more efficient to place a sub-function that is to be repeatedly called into a subroutine (once per record read when reading a large dbf).
- It is more important to have well structured, clearly written programs that are easy to understand and to maintain, than to have programs optimized to the last byte and call. ("It is easier to make a working program fast than a fast program work").
- Do not attempt too much in one program. A rule of thumb for RPG III programs is that programs start becoming unwieldy at 1,200 lines, are quite large enough at 1,500, and are getting unmanageable at 1,700 lines. At 2,000 lines, they are epic. (Ideally RPG III programs should be less than 700 lines).
Remember that RPG III and COBOL programs cannot be called recursively; for example, twice in the same invocation stack for a job. This puts limitations on how programs can be linked together. For example, if a maintenance program ca CAll an inquiry program, and the inquiry program ca CAll the maintenance program, the situation might arise whereby a recursive call is attempted.
Note: You may achieve a logical or design modularization which may be implemented in a redundant manner; for instance by the use of /COPY or %INCLUDE members in HLLs, or by the use of CA 2E internal functions.
The interface between any two programs can be regarded as a database format; it may be implemented as such, using externally-described data structures in order to allow for change.
