Grading Scheme for DLs and Graders
CS1010 AY2011/12 Semester 2
School of Computing
National University of Singapore

0 Introduction

This is the general marking scheme for take-home lab assignments. Please do not release this webpage to students.

There will be five take-home lab assignments, each consisting of 3 to 4 exercises.

For each lab assignment, 1 mark Attempt Mark is awarded to the student if he/she satisfies BOTH the following conditions:

1. That he/she has submitted ALL the exercises in that assignment via CodeCrunch before the deadline.
2. That the Feedback Mark for each exercise is at least 50 marks out of 100. This signifies that he/she has made a reasonable attempt on all the exercises.

Generally speaking, it's not our intention to hold marks of lab assignments. The central idea is, students must show genuine effort in learning and solving lab problems. Therefore, for example, if a student email you his/her programs slightly later than the deadline, you may still accept it with a warning for him/her. For very weak students, you may lower the bar for the second condition above a bit, e.g., award attempt mark if the average score of all exercises is above 50. When you submit your marks to the lab coordinator (zhaojin@comp.nus.edu.sg), please put a comment to whom you have given special considerations.

For Feedback Mark of each exercise, correctness constitutes 60 marks, style 20 marks and design 20 marks.

In general, style refers to typographical and documentation issues such as indentation and spacing, naming of variables, readability, proper comments, etc., whereas design refers to choice of algorithm, use of appropriate programming constructs, efficiency, modular programming, etc. Sometimes, when a certain item may not fit into style or design category, it is arbitrarily categorised under either one for convenience.

You should take a look at the skeleton program to see which part of the program is provided to the students, and which part the students have to fill in themselves.

Some information in this document is released to students in the document Lab Guidelines. Please read through.

1 Marking procedure

Please refer to IVLE for course schedule and the release dates of take-home lab assignments. Lab documents will be available for your preview one week before respective release dates.

Students are to do programming in UNIX using Vim, and submit their programs to CodeCrunch. After deadline, CodeCrunch admin will email you student programs. Then you may start marking according to this general marking scheme and additional marking notes associated with each lab, if any. After finishing, you may send emails to your students, attaching the commented programs and feedback marks. Meanwhile, you need to update your marking results with the lab coordinator (zhaojin@comp.nus.edu.sg).

Marking of lab assignments is to help students identify problems and suggest improvements. Therefore please avoid very negative comments in your marking (e.g., too bad a design!...). You may just insert your comments and feedback marks in their' programs.

You have the freedom to decide how many marks to deduct if you meet any case that is not specified in the marking scheme (which is quite common) - a mediocre mark deduction is fine. Meanwhile, your overall marking shouldn't be too lenient because students later may get shocked by their PE results (which is marked according to a strict marking scheme).

2  Correctness marks

Usually we set 5 or 10 sets of test data for each exercise. So each set of data deserves 60/5 or 60/10 marks.

If the student's program gives the right output, but the program's logic is not completely correct (because our test data is not able to catch it), please inform me so that we can set another test data. If we choose not to set another test data, you can deduct some marks (depending on severity, and this needs your discretion) from the Design part.

If student hardcodes the output, which happens to be the correct output for some of the test data, we will award zero mark for correctness.

If student's program violates the objective of the exercise, e.g., uses a syntax or method that is explicitly forbidden, then he should get zero mark for correctness, and also zero mark for Design.

If student's program fails all test cases because of some simple mistakes (e.g., extra blanks or typos in output, simple logic error), you have the right to override CodeCrunch mark and deduct marks manually based on your justification.

3 Style marks

For style, we will use a penalty grading scheme. Start with 20 marks, then deduct marks for each mistake, up to a maximum deduction of 20 marks.

We classify mistakes into 2 types: minor and major. Some examples are given below. If you spot any mistake that is not stated here, please judege by yourself.

Minor mistakes:

• Do not write name, or discussion group number, or in case where the program description is not given, do not write the program description: Deduct 1 mark for each omission.
  
  
• No function description at the beginning of a function: Deduct 1 mark.
  
  
• Where appropriate comment (apart from program description and function description) is absolutely needed but not present (occuring once or twice): Deduct 2 marks.
  
  
• Redundant or superficial comments: Deduct 2 marks.
  
  
• Improper/inconsistent indentation (occurring once or twice): Deduct 2 marks.
  
  
• Bad identifiers for constants, variable names or function names (occuring once or twice): Deduct 2 marks.

Major mistakes:

• A minor 2-mark-deduction mistake occurring more than twice in the program: Deduct 5 marks instead of original 2 marks.

Specific possible mistakes pertaining to the exercise will be released in the additional grading notes for that exercise.

4 Design marks

For design, we will also use a penalty grading scheme. Start with 20 marks, then deduct marks for each mistake, up to a maximum deduction of 20 marks.

We classify mistakes into 2 types: minor and major. Some examples are given below. If you spot any mistake that is not stated here, judge by yourself.

Minor mistakes:

• No initialization of variable wherever appropriate: Deduct 2 marks.
  
  
• Wrong variable type (e.g., a variable that should be integer, but a float is used instead): Deduct 2 marks.
  
  
• Wrong function return type (e.g., a function that should return an integer, but a void function is written instead): Deduct 2 marks.
  
  
• Unnecessary parameter(s) or insufficient parameter(s) in a function: Deduct 2 marks.
  
  
• Logic not quite neat (e.g., unnecessarily long code or complex 'if' statement which can be simplified): Deduct 2 marks.
  
  

Major mistakes:

• A minor 2-mark-deduction mistake occurring more than twice in the program: Deduct 5 marks instead of original 2 marks.
  
  
• Very complex/hard to understand logic: Deduct 5 marks.
  
  
• Using unnecessary function(s) or data structure(s): Deduct 5 marks.
  
  
• Gross inefficiency: Deduct 5 marks.
  
  
• (Very serious) Violation of objective of the exercise, such as using an explicitly forbidden syntax or approach: Deduct 20 marks from Design (and at the same time, zero mark for Correctness).

Specific possible mistakes pertaining to the exercise will be released in the additional grading notes for that exercise.

5 Appeals

Should any discrepancy, dispute or queries arise in grading, the students should first approach their respective discussion leader for clarification. The discussion leader should exercise his/her good judgment in granting appeals, bearing in mind the marking consistency among other programs with similar issues. If the appeal cannot be resolved with the discussion leader, the lecturer shall be the final arbiter in deciding an appropriate resolution.