APPENDIX B:RECOMMENDED SOFTWARE DEVELOPMENT PRACTICES This appendix is provided for informational purposes only, and is not a part of this standard. The following programming techniques should be used to facilitate analysis of the program, and to reduce the chances of programming errors. Deviations from these practices may be appropriate in some instances. * Each variable should have an associated comment that gives the range of allowable values for the variable. If the range is unrestricted, this should be noted. * Each procedure should have only one entry point. Each procedure should have at most two exit points, one for error exits and one for normal exits. * Control flow within a procedure should be defined using only the following constructs: sequence, if- then-else, while-do, case, repeat-until, for, and other structured loop constructs. * Data should be communicated between procedures through the use of argument lists and/or explicit return values. Global variables should not be used except where necessary for the implementation of an abstract data type. * Modules (which consist of data plus one or more associated procedures) should be constructed ac cording to the principle of encapsulation/information-hiding. * Each loop should be preceded by a convincing argument (as a comment) that termination is guaran teed. * Each procedure should perform only a single, well-defined function. * Each procedure should be preceded by a comment explaining the function performed by the procedure. * Floating point comparisons should not be used. * Where possible, variable names should be used in only one context within the same procedure. * Equivalence of variables should not be used to permit multiple memory usage for conflicting purposes. * Upon entry to a procedure, input parameters should be checked for appropriate values where possible. * The software should be hierarchically structured as a series of layers.