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.
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.
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!):
This is indented by two spaces per indent,
four is most common and eight is a little extreme.
Here it is without indentation:
Indentation standards
Throughout this module we shall expect the following:
Loops and if blocks to be indented with spaces, always
using the same number of spaces within each program (four is a
sensible value).
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.
The
closing "}" is on a line of its own aligned with
the first character of the starting statement, as in all
of our example.
All lines to be eighty characters long or less, for printing.
Blank lines
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
We expect variables to have the appropriate types. Reminder: some
things we count and some things we measure (and some things are
complex!)
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
The program (or equivalently the main() function)
should have a short comment explaining what the program does.
Comments within functions should be avoided except where it is not
possible to make the code self-explanatory.
Do one thing and do it well. This includes doing the
whole job, not just most of it.
Have a name that says what it
does (not "function1()" etc!)
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.
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.
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.
