STYLE GUIDE INTERNAL DOCUMENTATION Program Structure Modularity- Program should be broken into functional parts; each module (function, procedure) should be at most a page long Communication between modules must be through parameters (never global variables); I will discuss very limited exceptions Only data that is necessary for the intercommunication of modules should be declared in the main program. All data should be declared as locally as possible to its usage. No use of gotos Module Documentation Each module (including the main) must contain a header: FILE NAME AUTHOR DATE (including modifications) MODULE AIM PRECONDITIONS/POSTCONDITIONS Variables and algorithms should be explained (at right of code) Use meaningful identifier names; capitalize the first letter of each Each variable declaration should, in general, be on a separate line, with comments aligned on the right. Literals (numbers, strings) should be declared as constants in upper case Use all lower case for reserved words Consistent indentation should be maintained throughout, using a fixed number of spaces to indent each successive level of nesting within the program. Loop control statements and test statements should appear in their own line, above the statements they control. Comments improve comprehension throughout a program. Comments should be added to describe relatively long sets of related statements, algorithms that are not completely obvious, and any logical structure or group of statements that require special attention. In-line comments, to the right of a list of declarations, should line up. EXTERNAL DOCUMENTATION Architectural Diagram (structure chart, data flow diagram or other) Test Plan What input values you tested for; results of test Grading: 50% IT WORKS (FUNCTIONALITY SATISFIES REQUIREMENTS DOCUMENT) 20% INTERNAL DOCUMENTATION, ADHERENCE TO STYLEGUIDE 20% EXTERNAL DOCUMENTATION 10% OUTPUT CLARITY, ETC. Penalty for lateness Submit a disk with the hard copy.