Good coding practices are a major part of your final grade. Your
future boss might not care what your code looks like, but I
do. I will be looking at your svn code. The grade for coding
practices will be assigned mostly at the midterm demo and on the
Always remember to write code for someone else to read, someone
who knows nothing about the details of your program, because
that someone else is you, six months from now.
Refer to Chapters 10–19 of the textbook for details on
effective coding practices.
- Do you always ensure that argument values are valid?
- Declare variables close to where they are used.
- Initialize variables as they are declared.
- Do all variables have the smallest scope possible?
- Are references to variables as close as possible?
- Do control structures correspond to data types?
- Are all declared variables used?
- Does each variable have one and only one purpose?
- Is each variables meaning, and name, explicit? with no hidden meanings?
- Do your variable names follow your coding practice?
- Does the name refer to the real-world problem rather than the programming-language solution?
- Is the name long enough that you don't have to guess?
- Are computed-value qualifiers at the end of the name?
- Are loop index variable names meaningfull? i and j should only be used for loops of only a couple of lines.
- Have you re-named all "temporary" variables?
- Do you have any magic numbers?
- Does the code anticipate divide by zero errors?
- Are type conversion obvious?
- Do you avoid mixed-type comparisons?
- Are you doing integer division?
- Are you checking for integer overflow?
- Do you avoid adding or subtracting floating point numbers of very different magnituded?
- Do you avoid comparing floating point numbers for equality?
- Does the program use additional boolean variables to document conditional tests? to simplify tests?
- Do you use enumerated types instead of named constants when appropriate?
- Are all array indexes withing the bounds of the array?
- Are array references free of off-by-one errors?
- Are type names oriented towards the real-world entitites the types represent rather than toward programming-language types?
- Have you avoided re-defining predefined types?
- Does the code make dependencies among statements obvious?
- Do the names of routines make dependencies obvious?
- Do parameters to routines make dependencies obvious?
- Do comments describe any dependencies that would otherwise be unclear?
- Does the code read from top to bottom?
- Are related statements grouped together?
- Have relatively independent groups of statement been moved into their own routines?
- Is the nominal path through the code clear?
- Is the else clause present and documented?
- Are the if and else clauses used correctly—not reversed?
- Does the normal case follow the if rather than the else?
- Are complicated tests encapsulated in boolean function calls?
- Are the most common cases tested first?
- Are all cases covered?
- Is a while loop used instead of a for when appropiate?
- Is the initialization code directly before the loop?
- If it is an infinite loop, is it clear that it is? Is any exit clear?
- Is the loop body nonempty?
- Does the loop perform one and only one function, as a well-defined routine does?
- Is the loop short enough to view all at once?
- Is the loop nested to three levels or less?
- In a for loop, do you avoid changing the index variable?
- Do you avoid using the index variable outside the loop?
- Does the index variable have a meaningful name?
- Does the loop avoid crosstalk?
- Does the loop end under all possible conditions?
- Does the loop use safety counters?
- Is the loop's termination condition obvious?
Jose M Vidal
Last modified: Mon Jul 28 15:11:24 EDT 2008