Commenting 1 program should begin with a preface

Commenting
1) Program should begin with a preface stating:
a) Programmer's name
b) Date written
c) Course and assignment number
d) A summary or description of functionality, i.e., what the program does and a brief description of
how it does it.
e) Any known assumptions built into the program.
f) Any special instructions on how to run it.
2) All variables should have a brief comment explaining their purpose. Looping control-variables such
as: "X" or "i" need not be commented.
3) Comments within code should explain tricky or complicated code.
4) Comments should be clearly organized and easily distinguishable from the actual code.
5) Comments should be comprehensible and useful. Comments such as: “This adds I to M" are trivial
and should be avoided.
6) Each procedure or function should have a brief comment explaining the purpose of the procedure or
function. The comments might also state the limitations of the procedure and/or function using
possibly pre-conditions and post-conditions.
7) Comments should be indented to at least the level of the statements they describe.
Program Robustness
1) Do not check for equality among real numbers.
2) Prevent the abnormal termination of a program due to input error, check for the validity of the data
when appropriate.
3) Programs should not be built around a specific data set. Programs, unless otherwise stated, should
work correctly for any reasonable test data set.
4) Do not use GOTO statements.

I/O Behavior
1) All I/O should use a proper format:
a) All real number output should be formatted in decimal form unless scientific notation is
appropriate.
b) All input from the keyboard should be preceded by a prompt telling the user what format is
expected. For example, "Please Input the Date in mm/dd/yy format".
2) Label all output values. Remember, the output of a very complicated and elegant program is useless
unless one knows how to interpret the output.
Modules and Modular Program Structure
1) Module coherence:
a) Each module should correspond to one subtask in the overall algorithm to solve the problem.
2) Module independence:
a) Each module should be independent, i.e., it should be self-contained and it should perform its task
successfully without needing to know the inner workings of the calling module.
3) Procedures or functions should, in general, occupy at most 50 lines.
4) Use appropriate parameters rather than global variables. Avoid side effects.
5) Hide any information from the caller that it does not need. The default should be to hide information
unless the caller actually needs it.
Program Testing
1) The program should follow the program specifications delineated in the problem statement.
2) Testing should be sufficient to thoroughly check all parts of the program.
3) Make sure that the output of your program illustrates that it does in fact solve the problem.