Your mark for the course will be the sum of the marks for the five individual checkpoints, multiplied by the fraction of the first five checkpoints completed, minus half of any marks above 60, plus the mark on the final checkpoint. Under this marking scheme it is very important that you complete the first five checkpoints. Checkpoints done by presenting the model code count as completed.
e.g. if you get 15/20 for the first four checkpoints and don't do the fifth, you will obtain a third class mark: 60*4/5=48%. if you get 15/20 for the first four and just 1/20 for the fifth you will get an upper second mark: 61*5/5 - 1/2=60.5%. If you get 19/20 marks on the first five checkpoints and 10/20 on the final one you will get 87.5%. Feel free to write a computer program to simulate this!

The final marks for Computer Methods may be rescaled in the light of the marks for Computer Simulation (and vice versa). The principle for this is that nobody should be penalised for taking the more advanced course.

The demonstrators and staff will assess checkpoints according to the following criteria and performance measures.

Note that having a working code is only half the story. You must be able to explain clearly to the demonstrator how the code is designed, and similar information must be present in the code itself so that someone else could reuse and modify the code. A good way to do this is to use pseudocode. If you present someone elses code, or a commented version of the model code, you can score marks only for the second two catagories (i.e. maximum 10/20)

Pseudocode is typically a flow chart of the structure of the code. It is not written in JAVA and represents a pictorial view of the algorithm. It is a good idea to plan your code before writing it, to determine what classes you will need, how the loop structure will go, and what information is required by which class. Clearly written pseudocode will help enormously when you come to explain to the demonstrator how the code works.

Object oriented programming design may help here, but it neglects the importance of algorithms in solving physical problems.

1. Code completion and execution (50%)
   1. The code ran with no known bugs.
   2. A few bugs are present, but they are documented and possible fixes proposed.
   3. The code includes unexpected or unreported bugs.

   
   

   1. The code did all the checkpoint asked for
   2. Most of the functionality described in the problem statement was apparent in the code, but there were omissions
   3. The code is seriously deficient in its functionality
2. Student comprehension (25%)
   1. The student clearly understood both the language syntax / constructs AND the objectives / limitations of the checkpoint. The student clearly understood the key features to be developed; the scope of problem was well-defined.
   2. The student seemed to have a reasonable idea of what was being asked, both in terms of the language constructs and the specific checkpoint exercise. Limited attempt to define the problem.
   3. The student showed clear lack of insight into the constructs used and the checkpoint subject matter. Did not understand what is required.

3. Code design, layout and readability (25%)

   Analysis of problem

   1. Clear and well-documented design.
   2. Some design attempted, but did not fully understand OO approach.
   3. Started coding with no attempt at design.

   
   Pseudocode

   1. Appropriate use of pseudocode if required.
   2. Some attempt at pseudocode.
   3. No pseudocode used to develop algorithms.

   
   Class, method and variable names

   1. Used meaningful names and systematic naming convention to enhance code readability.
   2. Mostly used meaningful names, but no overall cohesion to approach.
   3. Used cryptic or meaningless names.

   
   Code comments

   1. Code commented appropriately throughout.
   2. Some comments included but not consistently.
   3. Code not commented.

   
   Code layout

   1. Correct use of indentation
   2. Some indentation used but not throughout the code.
   3. No indentation used.