DAT2219d PROGRAM DEVELOPMENT & CODING STANDARDS

1. Naming Standards
2. Input-Transform-Output Feasibility Chart Standards
3. Data Dictionary Standards
4. Pseudocode Standards
5. Flowchart Standards
6. Hierarchy Chart Standards
7. C/C++ Coding Standards

Naming Standards

1. Variable names will be expressed in camelCaps

2. Named constants will be expressed in ALLCAPS

3. User defined function names will be expressed as LeadingCapCamels

4. Names will be descriptive of purpose. Single letter variable names may be used for array indices and similar purposes, provided the range of meaning does not exceed 5 contiguous statements.

Input-Transform-Output Feasibility Chart Standards

1. All ITO charts will contain the headings INPUT, TRANSFORM(S), and OUTPUT.

2. The columns of an ITO chart will be separated by vertical lines; the headings will be separated from the body by a horizontal line.

3. The OUTPUT column will identify all variable outputs; that is, headings and constant identification strings should not be included in this column. Descriptive selection or repetition indicators should be used for individual outputs or groups of outputs which occur only under certain conditions or which occur multiple times.

4. The INPUT column will be separated horizontally into two areas:
   a) Variable input values; and
   b) Constants.

5. The "variable input values" area of the INPUT column will identify the source (typically "user" or some specific file identification) and under the source the fields required for the input solution (no more than one such field per line). The source should be underlined. A source and its fields should be separated from other sources and their fields by at least one blank line.

6. The "constants" area of the INPUT column will supply the (current) value for each named constant (as well as its name).

7. The TRANSFORM column will contain the definitions used for generating OUTPUT values from INPUT values. In general, each OUTPUT value must be defined in terms of INPUT values or in terms of itermediate values which are further defined in the TRANSFORM column (eventually in terms of INPUT values). The TRANSFORM colum will not include process activities such as input or output.

8. TRANSFORM rules will not use literal constants (only named constants).

9. TRANSFORM rules typically should include "intermediate" variables for the simplification of complex definitions whenever a complex requirement can be broken up into meaningful simpler elements.

10. Most TRANSFORM definitions should be of the form:
          variable = expression
    or
          variable is expresssion
    where expression is:
        an arithmetic expression, or
        "sum of" some field "for" some selection criteria (possibly "all"), or     "count for" some selection criterial (possibly "all"), or     a collection of alternative values (possibly in the form of "expressions") based on some selection criteria (this may be supplied as a table).

Data Dictionary Standards

1. The Data Dictionary should be divided into 3 vertical columns with the titles "NAME", "TYPE", and "DESCRIPTION", in that sequence. The columns must be separated by vertical lines and the titles must be separted from the body by a horizontal line.

2. The body of the Data Dictionary should be divided into 3 horizontal areas (in some cases not all areas will be used): "Structures", "Constants", and "Variables". Each area should be separated from the others by a horizontal line.

3. Within the "Structures" area, each structure will be identified by name and under that name will appear a list of the elements which make up that structure. The structure name must be clearly identifiable in a way that it can not be confused with its elements. "TYPE" information will be supplied for each element (but not for the structure name).

4. Under the "TYPE" heading each named value (except for structure names, as noted above) will be identified as int, float, char, or some structure name (declared in the "Structures" area); if the value is an "array" the number of elements in the array must be specified here as well.

5. Under the "Description" heading, a description must be provided which describes the meaning of each value in non-ambiguous terms, when this meaning is not obvious from the value name; no two values should have identical description entries.

6. Within the "Constants" area, the value of each constant should be supplied under the "Description" heading (prior to any description).

Pseudocode Standards

1. Each module will begin with an underlined title.

2. The main module will end with END, vertically aligned with the main module's title.

3. Modules other than the main module will end with RETURN or RETURN value, vertically aligned with the module's title.

4. Only one END or RETURN is permitted in any module.

5. The body of the module will be indented (3 or 4 spaces) relative to the title

6. "PROMPT for and GET ..." may be coded as a single action; however only a single value is to be input with an action, unless the sequence of entry of the values has no significance.

7. "DISPLAY ..." will be used to output to the display screen.

8. "OPEN file", "READ record from file", "WRITE record to file", "CLOSE file"
       will be used for file I/O

9. Selection will be handled using:
       IF condition ... ENDIF
       IF condition ... ELSE ... ENDIF
   or
       IF condition ... ELSEIF condition-2 ... ... ELSE .... ENDIF
   

10. Repetition will be handled using:
        WHILE condition .... ENDWHILE

11. The actions which make up the body of Selection and/or Repetition structures will be indented (3 or 4 spaces, consistently) relative to the IF, ELSE, ELSEIF, ENDIF, WHILE, or ENDWHILE lines.

12. No logic flow structures other than Sequencial (the default) and the Selection and Repetition forms identified above will be used.

13. Variable, constant, and structure names used in pseuod-code should match those declared in the data dictionary. Declaration of variables, etc. is not part of the pseudocode.

Flowchart Standards

• (As employed in lectures).

Hierarchy Chart Standards

• (As employed in lectures).

C/C++ Coding Standards

1. Every program will begin with identification comments which will include:
   a)    the name of the source (.CPP) file
   b)    a description of the purpose of the program
   c)    the author's name
   d)    the date the program was written
   

2. For any structure which has the basic sequence:     header { body }
   the openning bracebracket ( { ) will be coded directly under the first character of the header; the closing bracebracket ( } ) will be coded vertically aligned with the openning bracebracket.
   The body will be indented (3 or 4 spaces, consistently) relative to the bracebrakets.

   This rule applies to function definitions, if, else, and while flow controls and structure declarations. It does not necessarilly apply to array initialization statements.

3. The header for the main function will be:
       void main(void)

4. Variables, constants, and structures will match the names defined in the data dictionary (and therefore, the naming rules of the data dictionary apply to code).

5. Within DAT2219d only those language structures which are considered most "portable" to forms used in other languages will be used. Coding should include only those forms demonstrated in class.

6. Global variables are to be avoided.

7. Struct declarations should be global (before and outside of any function definition).

8. Constant definitions may be global or local depending upon their preceived scope of application.

9. Within a function, all variables should be defined before other processing activity.

10. Structure declarations (or any other user-defined type declaration) must occur in separate statements from variable definitions of this type.

11. Each variable and/or constant must be defined in its own statement.

12. Record processing of fixed-structure files will always have the form:
    1.    read the first record
    2.    WHILE not some terminal condition
    3.            process the record
    4.            read the next record
    5.    ENDWHILE
    (This, of course, assumes the file has been openned successfully, an activity which must always be done and always checked).

13. Constant literal strings will not be used for file paths. (Prompt for and get this information from the user).

14. Any reference to an element of an array will be of the form:
          arrayName [ ndexValue ]

15. Complex arithmetic or Boolean expressions will use parentheses and not rely on precedence rules to make the order of evaluation clear.

16. Whenever reasonable complex arithmetic expressions will be written as a series of simpler arithmetic assignment statements. (By "reasonable" we mean that sub-expressions can be given some meaningful identification).