1. Devise a scheme that is compatible with these style rules and follow it consistently for each of the following:
   • horizontal spacing (indentation, blank lines)
   • vertical spacing (use of blank lines to enhance readability)
   • capitalization (storage locations, key words)
   • multi-line statements (dividing long statements among two or more lines)

   Note well: these rules are not always consistent with those used in the textbook or with code I write in class to illustrate Pascal concepts.

2. Put a least one space on either side of all operators (arithmetic, relational, logical and the assignment operator. Example:

       Average := Sum / Count;

3. Put a space after a comma separating items in a list. Example:

       Writeln(Name, Exam1, Exam2);

4. Avoid wraparound, either in comments or lines of code.

5. Put at least three blank lines between adjacent module definitions.

6. Put two blank lines above and one below each block annotation (unless the annotation is at the top of a BEGIN-END block, in which case there is one blank line above and below the annotation).

7. Separate adjacent sections in a module by at least one blank line (decide on a number to use and use is consistently).

8. Don't insert blank lines indiscriminately; use them only as called for in the three previous items.

9. A block annotation should have the same indentation as the annotated code (put the opening "{" in the same column as the first character in the code).

10. The opening and closing lines of any bracketing structures (BEGIN-END, CASE-END, REPEAT-UNTIL) should have the same indentation. The bracketed code should be indented one level. An ELSE should have the same indentation as its matching THEN and both are indented one level relative to the matching IF. The statement after THEN or ELSE (whether simple or compound) should be indented one level. The statement after FOR-DO or WHILE-DO (simple or compound) should be indented one level. END is always on a line by itself; BEGIN and REPEAT always end the line they are on; THEN and ELSE (or ELSE IF) should always start on a new line (apart from documentation). Label BEGIN and END if the bracketed code contains a nested bracketing structure. Label the BEGIN and END bracketing the execution block of any module. The statement (simple or compound) after the ":" in a CASE clause begins on the same line as the ":". A typical nested IF-THEN-ELSE structure should look as follows. The rule is: each ELSE must align with its matching THEN.

        IF <Boolean expression 1>
          THEN <Statement 1>
          ELSE IF <Boolean expression 2>
                 THEN <Statement 2>
                 ELSE <Statement 3>

11. Statements in sequence in the same structure should have the same indentation.

12. Do not use superfluous BEGIN-END statements. Examples:

    Superfluous:        If Score > 90
                          Then      
                            Begin
                              Writeln('Super!!! ')
                            End
    
    Not superfluous:    If Score > 80
                          Then
                            Begin
                              If Score > 95
                                Then Write('Super!!!');
                              Writeln('Congratulations')
                            End
                          Else Writeln('Not bad!')

13. Do not embed calculations within Write or Writeln statements. For example, do not code as follows:

        Writeln('The average is ', Sum / Count)

    You must explicitly calculate the average, placing it in an appropriate storage location:

        Average := Sum / Count;
        Writeln('The average is ', Average)

    
    
14. Do not use hard-coded constants (often called magic numbers) embedded in your code (other than 0, 1 or 2). Define quantities which will not vary during program execution appropriately in the Constant section of the program. For example, the code in an example above should be written:

        Const
          Low_A = 90;
    
        If Score > Low_A
          Then Writeln('Super!!! ')

1. Identifiers should be meaningful in that they suggest the way the identifier is used in the program or what kind of data is stored in the variable ("self documenting code").

2. Use selective capitalization or selective non-capitalization when using the underscore character; for example, RegionalTotal or Regional_total.

3. When in doubt, avoid abbreviations entirely (e.g., Quarterly_subtotal is better than QSubtot).

4. Type an identifier the same way each time it occurs in your program (even though the Pascal compiler is not case sensitive).

Your program output should be neat and readable with adequate titles, labels and any columns aligned in a reasonable way. Make different sections of output discernible by using more "white space" to separate sections than is contained within a section.

1. After the program heading but before the Constant definitions, include a typed and boxed program prologue giving your name, section, due date for the program, value of program and a statement of what the program does that is clear, correct, complete and concise. Find and correct all misspelled words and poor grammar in all documentation. A typical example:

       {    Program Assignment:  #??
            Title:  <as appropriate>
            Workfile name:  PRG?_S98
   
            This program is designed to .....
   
            Programmed by:  ?????
            Section:        ??
            Due date:       ?????
            Value:          ?? pts.                     }

2. Precede each module (procedure or function) with a boxed prologue giving a description of what the module does that is clear, correct, complete and concise. This description should include an explanation of any module input (via parameters) and, in the case of functions, the value (and type) returned. The description should say what the module does, NOT how it accomplishes that task.

3. All code in execution blocks that contain more than 3 to 5 lines of code should be annotated by block annotation (comments which say what task is accomplished by the following block of statements). The code should be divided into blocks in such a way that the statements in a block together perform one logical task (that can easily be completed stated in the block annotation). Such block annotations may occupy one or more line. Start with a phrase in the imperative; e.g., { Compute averages }, { Update sums }, or { Remove lead blanks }. Subsequent phrases, if any, should be complete sentences; e.g., { Read the next line of the file }.

4. Program identifiers that are mentioned in documentation should appear exactly as they do in the code and should be set off on either side by two spaces.

5. Include "same-line" comments where they would serve to help the reader understand a particularly obscure line of code. For example,

       If (FOUND)                  { If the target name is found in the list... }
         Then
           Begin ...

1. Follow any logical requirements that are part of the programming assignment.

2. Don't declare variables or parameters which are never used.

3. Use IF-THEN rather than CASE for a 2-way branch.

4. Use CASE rather than IF-THEN-ELSE (whenever possible) when the level of nesting exceeds three.

5. Use type BOOLEAN for program flags (a "flag" is a variable whose value indicates which of two possible states (True or False) has been obtained at a given point in a program).

6. Explicitly initialize all variables when needed (do not rely on compiler defaults!).

7. Your program should not do unnecessary processing.

8. Avoid hard-coded constants (other than 0, 1 or 2, or other values with intrinsic eaning).

1. Write in the upper right-hand corner of each page of both your program listing (printout of your program source code) and your program output your name, section, date and the number of the programming assignment. For example:

                          <your name>
                          171-<your section>
                          <assignment due date>
                          Program <number>

2. Please tear off the detachable strips on the sides of tractor feed paper!

3. Turn in all programs in a folder as described in class. Do not keep back work in your folder; turn in only current work which is due. NEVER throw away any work turned in for credit during the course; keep such work in a safe place for reference should a dispute arise later in the semester.

4. When turning in redos, turn in the original assignment with the redo.

1. Never attempt to write a program from scratch on the Turbo Editor. Working in this way can only lead to frustration and disaster! Before ever typing a program using the Turbo Editor, the main outline of the program should be carefully written out, including all declared constants, required storage and the main- line code. Complex pieces of the program can be delayed until a later time. Put a comment to that effect in the code; for example { tax computation routine will appear here }.

2. Debug as you go! Never wait until 98% of the code has been typed in to try it out! Write a small portion of the main-line code, checking that easy portions of the code are working correctly; e.g. files are being opened and closed properly, output is correctly aligned, totals are being correctly maintained, etc. When writing procedures and functions, write messages from within procedures and functions to determine that they are being called in the proper sequence. Use procedure stubs: delay writing the code for a procedure until you are certain that all procedures are working together properly. Then write procedures and debug them one at a time! Never attempt to work on the code for several procedures at once (changes in two can have unintended cross-over effects!). Continue working on a procedure until you are satisfied that it produces correct results with suitable test data. Then go on to the next procedure. In this way all procedures are built as they are needed and debugged thoroughly as they are added, isolating errors to the last module added to the program.

1. The program must run correctly and give correct output for the prescribed range of possible input data. A program which does not satisfy this requirement will be returned as a "redo." A redo must be corrected and resubmitted to receive credit on the assignment (turn in the original program listing and original output along with all corrections, properly labeled). Late penalties accrue from the due date until a correct version of the program is handed in. However, even extremely late programs will be given a scrap value of up to 10% of their original value. Please note: an absolute last day to turn in programs for credit will be announced during the last few weeks of class.

2. Programs are due no later than 3:00pm on the specified due date (unless stated otherwise). A late penalty of 10% for each 24 hour period beyond the original due date will be assessed for programs handed in late (with 3:00pm Friday to 3:00pm the following Monday counting as two 24 hour periods). For example, a program due at 1:00pm on Friday and turned in before 10am on Monday would likely receive only a 15% late penalty, but a program turned in at 3:30pm on Monday would likely receive a 25% late penalty. PLEASE NOTE: PENALTIES FOR REDOS ACCUMULATE FROM THE ORIGINAL DUE DATE, NOT THE DATE THE PROGRAM IS RESUBMITTED!

3. All programs, including those handed in "late" and those resubmitted as "redo" must be turned in to the MCS Office, 104 McGraw Hall, where they will be stamped with the date and current time. Programs slipped under the MCS Office door (not my office door) when the MCS Office is closed will be stamped with the time the office next opens. Programs submitted in any other manner will not be considered "handed in." DO NOT HAND IN PROGRAMS IN CLASS, give them personally to me, slip them under my office door, hand them in to the Mathematics Office, or submit them in any other manner except that prescribed here.

4. For each programming assignment, turn in both a printout of your documented and annotated source code and a printed copy of one or more (as needed) program runs. At times you will also turn in a diskette containing your source code (as specified in the program assignment).

5. Your course grade will be lowered one letter grade for every program assigned for which no correctly working program with correct output is ever submitted and received.

6. The criteria for grading correctly working programs will include style and layout of source code (neatness, readability, consistency, observation of stylistic rules), choice of identifier names (names should be meaningful and abbreviations avoided), appearance of the output (neatness, readability, layout, proper use of headers, etc.), documentation and annotations, correct logic design, organization and efficiency and other issues which we may discuss in class.

7. Programs turned in late, after programs have been returned to students in class, will earn at most 25% of their original value.