CSE2304, Practical Work Marking and Style Guide 2004

Marking

1. You must prepare the practical exercises before coming to the laboratory.
2. If you do not submit a program that is a reasonable attempt and compiles without error by the end of the laboratory, you will receive between zero and at most half marks, and quite possibly zero.
3. If the program does not run and give reasonable results on at least straightforward input cases, you will almost certainly receive less than 60% marks.

Coding Style

Good:

1. Indentation, must be used in some sensible and consistent way.
2. Pre- and post-conditions for routines especially if non-obvious.
3. Invariants for loops.
4. Assertions for difficult and non-obvious conditions.
5. Larger program divided up into sub-routines and sub-files in a sensible way.

N.B. Consistent means "used in the same way in the same type of context" not necessarily in all contexts. The style advocated in theStyle guide is not my favourite, but it is "ok" and beginners may find it helpful.

Bad:

1. Non-informative comments such as this: /*increment i*/ i++;
2. Excessively deep indentation, e.g. past the middle of an 80 column page.
3. Exercises in C obfuscation, e.g. (p++)->f--, etc.

Names

Use sensible and informative names for variables and routines.

Short names are risky, but can be appropriate sometimes, e.g. T can be a sensible name for a Tree, especially capitalised, in a short routine, where there is only one Tree variable in use, or one main Tree. Note also that i, j and k are so ingrained as the names of general purpose loop-control and index variables in Mathematics and Computing that they can be informative for that purpose unless more obvious terms suggest themselves. Similarly x, y and z for Cartesian coordinates.

Nouns often make good names for variables, e.g. break_point, location, segment, rotation.

Adjectives often make good names for predicates, i.e. boolean functions, e.g. odd(m), even(n), null(list), full(queue), empty(T), balanced(T).

Screen Viewing

Programs are now most often viewed on a computer screen, which has a much smaller effective size (rows and columns) than paper. (The school's line-printer went to the scrap yard ~2000(?) and it had been unused for a couple of years before that.) So formatting a program to make it more easily read on a screen is, within limits, useful. e.g. The following can be acceptable in some situations

if( x < y ) min = x; else min = y;

if( x < y )
   min = x;
else
   min = y;

if( x < y )
  {
    min = x;
  }
else
  {
    min = y;
  }

min = x<y ? x : y