The aim of this page is to tell students and markers what is expected of their work.

General expectations

Comments and questions to John Rowe.

We are looking for programs that:

1. Are simple, clear and easy to understand.
2. Are written in a way that minimizes the possibilities of mistakes, and ensures that any mistakes made more likely to be flagged by the compiler, and easier to find when debugging.
3. Correctly perform the required task.

These will be evaluated as if the exercise set was part of a medium sized programming project. Exercises will be set and assessed according to the standard expected of a student with no previous programming experience.

Incomplete or incorrect programs

Incomplete programs will be given a mark roughly in proportion to the fraction of the program that has been completed. Programs that are complete but do not work due to a bug will lose at most 20% of the mark (note that this refers to programming errors, errors that suggest that the programmer is attempting to solve the wrong problem may lose more marks).

Specific expectations

The general expectations above always apply, the purpose of this section is to apply those general principles to the aspects of the C language we have learnt so far.

Thus this list grows as the module progresses but the expectations from previous weeks still apply.

Week 1 onwards

Indentation and white space

We said in the lecture that professional projects expect perfect indentation. This sounds petty but it isn't. Properly indented programs are much easier to understand.

Example

Here is a simple example of an if (properly indented of course!):

/*
 * Simple if demonstration
 */
#include <stdio.h>
int main() {
  int mustbepositive = -2;      /* !! */

  if ( mustbepositive >= 0 ) {
    printf("OK: %d\n", mustbepositive);
    return 0;
  }
  else {
    printf("ERROR: it's negative: %d\n", mustbepositive);
    return 1;
  }
}
 

This is indented by two spaces per indent, four is most common and eight is a little extreme. Here it is without indentation:

/*
 * Simple if demonstration with no indentation
 */
#include <stdio.h>
int main() {
int mustbepositive = -2;      /* !! */
if ( mustbepositive >= 0 ) {
printf("OK: %d\n", mustbepositive);
return 0;
}
else {
printf("ERROR: it's negative: %d\n", mustbepositive);
return 1;
}
}
 

Indentation standards

Throughout this module we shall expect the following:

1. Loops and if blocks to be indented with spaces, always using the same number of spaces within each program (four is a sensible value).
2. The starting "{" of a block should either be on the same line as the statement (as above) or immediately below the first character, on a line on its own:

       if ( x > 0 )
       {
           printf("x is strictly positive\n");
       }
   

   (here we have demonstrated four spaces per indent for variety). The same style must be used throughout each program.
3. The closing "}" is on a line of its own aligned with the first character of the starting statement, as in all of our example.
4. All lines to be eighty characters long or less, for printing.

Blank lines

1. Single blank lines can be useful inside a function to indicate different steps in the algorithm, and is very sueful after variable declarations. Do not have two consecutive blanks lines inside a function as this will be visually confusing when we start to have multiple functions in the same file.

Variables: type and names

1. We expect variables to have the appropriate types. Reminder: some things we count and some things we measure (and some things are complex!)
2. Variables should have desciptive, but fairly short names. The best starting point is to ask "what would I call this if I were explaining it to my tutor?".

Comments

1. The program (or equivalently the main() function) should have a short comment explaining what the program does.
2. Comments within functions should be avoided except where it is not possible to make the code self-explanatory.

Week 3 onwards

Functions

A function should:

1. Do one thing and do it well. This includes doing the whole job, not just most of it.
2. Have a name that says what it does (not "function1()" etc!)
3. If there is any chance of ambiguity it should have a comment immediately before it to resolve that ambiguity.

Failure to write and/or call functions when instructed to

Being able to write and call functions is a key programming skill. For this reason some exercises and assessments specifically state that a function should be written or called:

• Write a function..
• Call a function...

In these cases simply putting the code that would form the body of the function inside the calling function such as main() is not acceptable. Failure to write and call a suitable function when specifically instructed to will result in an extremely poor mark.

Remember, if you are not sure how to write and call a function we are happy to show you (except in the CA test!).

Input/output

• Calls to fopen() should always be checked for NULL and appropriate action taken. Usually a clear error message and a call to exit() is sufficient.
• Unless otherwise stated, input from the keyboard should be checked for validity and the user given a chance to try again. This may be, for example, by having the input statement inside an infinite loop that breaks only when the input is valid, or by returning to a menu function.

  The user should always be given a helpful error message that makes it clear what the problem was.

Indentation and white space

Functions should have two or three blank lines separating them from the previous one. These occur before the comment, with no blank line between the comment and its function.

Week 4 onwards

Arrays

Arrays will have their sizes set by a #defined constants and all other parameters, such as loop limits etc., shall be arranged such that changing the #define causes everything else to change in step.

Week 6 onwards

Structures

• Every type of "thing" in a problem that cannot have all its details represented by an existing type (int, double, array etc) will normally have its own structure type.
• The structure will contain everything need to describe each individual "thing" and nothing else. (Ask ourselves: "if I had two of these things what would I need two of to describe them?". Those things go inside the structure).
• The structure type will have a descriptive name, assigned using typedef, such as "Particle", "Student", "Star", not "Structure1", "Structure2" etc.
• Each structure type wil have a function whose job is to allocate a new one and set it to an allowable state.
• Functions will receive pointers to structures as arguments and will use these to access and change individual structure members.