Rules and Recommendations

Most of the following rules are universally accepted.

General
1. Since real programs are frequently modified, the text of programs must be understood by others. Be careful and pay attention to the clarity of your programs! 2. Efficiency should never be pursued at the expense of clarity. 3. Think to the correctness of your programs. An incorrect program is useless. 4. Use a Pseudocode to design the algorithm [Kernigham74, Freniu*] 5. Keep Methods Short. A subprogram (function, or procedure) should not be longer then 50 lines. Longer function or procedures indicates that they are too complex, and need to be broken into separate functions. 6. Write Design Documentation. 7. Define the problem completely [Gri81, Led75]. 8. Think first, program later [Led75]. 9. Use Top-Down Design [Flo79, Gri81, Sch90] (And its relatives "Stepwise refinement" [Wir71], or "Divide and Conquer"[Gri81]). 10. Write and use modules as much as possible [Dah72, Gri81, Sch90]. 11. Use Structured Programming [Dah72, Flo79, Sch90]. 12. Prove the correctness of algorithms during their design [Dij75, Gri81, Dro95]. 13. Insert the assertions in the text of programs and verify their correctness during debugging process [Gri81] 14. Do not overlook the special cases of the problem [Nau66]. 15. Define and use Abstract Data Types (ADT) [Sch90]. 16. Design input-output routines for each ADT [Sch90]. 17. Verify each part of a program as soon as possible [Sch90 ]. 18. Hand-check the program before running it [Led75, Kin76]. 19. Do not forget to test your program, even if you have proved its correctness [Gri81]. 20. Write the documentation of the program simultaneously with its building [Sch90]. 21. Strive for continuing invention and elaboration of new paradigms to the set of your own ones [Flo79]. 22. Be careful at the parameters of procedures [Sch90] 23. Conceive a procedure independently of the context where it is used (make it general) [Frentiu*0b]. 24. Use the FOR statements properly; do not change the value of the counting variable, or the limits inside the cycle [Led75, Gri81] 25. Do not exit a FOR cycle through a GOTO statement [Led75, Fre93] 26. Avoid GOTO statements [Dij68] 27. Avoid tricky programming [Mey88], or Write clearly dont be too clever [Kernigham74] 28. Ask for computer assisted software development [Gri81, Sch90]

29. Test your program in small pieces, as you develop it [Kernigham74, ]

Variables
V1. Decide which are the needed program variables, and what are their meanings [Led75, Gri81]. V2. Explicitly declare every single variable V3. Document variables where they are declared V4. For each variable of a program, make sure that it is declared, initialized and properly used [Nau66]. V5. Verify the value of a variable immediately it was obtained [Flo79]. V6. Avoid to use global variables (you may use global variables only with a special approval of your teacher) [Frentiu*0b, Sch90]. V7. Nevertheless, if you have to use global variables, choose long and meaningful names composed of capital letters. V8. Use auxiliary variables only if it is necessary, if there is a reason to use them. V9. Be careful when you compare two real values [xxx] V10. Keep the number of parameters of a subprogram at a minimum by: - structuring your data; - dividing the subprogram into smallest ones.

Comments
C1. Use comments to document your program [Led75]. C2. Comments must be written as you write your program (not later!). C3. All of the major elements must be commented to describe what they do/how they work: - the meaning of each variable and other constructs used in the program; - for each program, or unit of program: - the author of the program; - the date, in the format yyyy-mm-dd; - the version number; - description of changes made in the previous version. - for each function or procedure: - a description of what the subprogram does; - the parameters (arguments) and their meaning; - a specification of the subprogram (precondition + postcondition); - for each loop, the invariant and the bound function; - in some places of the program the condition to reach that place, or the role of that part of the program; - other useful information for the reader. C4. Comments must be as few as possible, but as many as necessary! C5. Avoid obvious comments (For i:=i+1 do not comment i is increased by 1). C6. Incorrect comments are worse than not at all! C7. When you modify a part of program be sure to modify the comments to keep them accurate.

Names
N1. Choose suitable and meaningful names for variables, and other constructs [Led75]: - nouns for variables, verbs for activities, adjectives for conditions; - the name reflect the meaning of the variable (meanValue, not m). - when a name is composed of two or more words, start the second (third,) with an uppercase letter; N2. Use symbolic names for all entities (constants, types, variables, procedures and functions) [Frentiu*0b,.] N3. Use simple short names for loop counters (for example, i, j) N4. Use uppercase and lowercase letters to distinguish different kinds of names (for example, all variables start with a lowercase letter, meanwhile types, functions and procedures start with an uppercase letter; N5. When a name is composed of two or more words, the second, third and so on start with an uppercase letter (numberOfPersons). Use the upper and lower case consistently.

Typography
T1. Think to pretty writing the text of the program [Led75, Sch90] T2. Use spaces to separate various constructs; all identifiers are surrounded with white spaces T3. Use one or two blank lines between all methods T4. Use the occasional blank line to break up related chunks of code T5. Keep parenthesis visible. T6. Respect the following indentation rules [Gries85]: - Indent subcommands of a command 3 or 4 spaces from the column where the command begins; - Commands of a sequence that appear on successive lines should begin in the same column; - The pre- and postcondition of a command should begin in the same column as the command; - A loop should be preceded by an invariant and a bound function; these should begin in the same column as the beginning of the loop.

Others
O1. Choose suitable data structures. The complexity of algorithms depends on this choice!