|
I don't know of any central source for RPG programming standards. I know of few technical subjects that stir stronger passions than the subject of programming standards. There always seems to be two camps, those who want little to no standards, and those who want to make a rule for everything. Programming standards are individualized per IT shop and are somewhat affected by the type of company you work for. You should develop standards that are right for your shop and organization. I generally favor making programming standards for the important things and keeping the list small enough that people can remember them. Attached is a partial list of some things you may want to consider along with some notes that may serve as food-for-thought.
Object naming conventions-- Do you have a naming scheme for Physical files, field names, logical files, RPG program setc?
File definitions -- External or program described, do you use a field reference file, Do you key physical files or only logical files, etc.?
Subfile processing -- How do you build and process your subfiles? (There are at least three primary ways to build and process them.)
Guidelines on Coding Style
Record locking -- How to avoid or deal with record lock issues?
Reports-- Definition of standard report headings and trailers. Are print files externally described, or program described?
Standard error message handling--Do you use a message file for error messages, or are they program described ?
Work management/security-- What does your standard library list structure look like, etc.?
CRT screen design standards--For Green Screen applications, SAA standards are the norm.
Standard function key definitions-- For Green Screen applications, SAA standards are the norm.
Standard option definition--For Green Screen applications, SAA standards are the norm.
Also, here are a few coding style guidelines to consider that are hopefully not too controversial.
** Text will be provided in the beginning of every program describing its function and purpose.
** When modifying an existing program or file, maintain a modification log in the header of the source that contains your name, the date of change and the description of the change.
** Document for clarification and readability; do not over-document.
** Write all programs using modern structured programming techniques.
** Format a program to help the reader understand it.
** Modularize, use subroutines.
** Use descriptive variable names.
** Limit the size o nested DO loops and IF statements Less nesting is usually better.
** When commenting out executable code, use more than 1 asterisk to make it more obvious that the code is no longer executable A minimum of four asterisks is recommended.
|
