Project Grading
Grading Policy
Projects will be graded on four criteria: correctness, design, efficiency and conformity. A program that simply "works" might be correct, but will not receive a score of 100% unless it also has good design, is efficient and adheres to coding standards. Here are some general guidelines for each criterion.
- Correctness: To receive a good score for correctness, you
must implement all of the required features of the project as stated in
the project description. Your program must also run without error on all
inputs — including inputs that were not provided in the project
description and inputs that you did not try. (Think about this.)
Your program must not leak memory.
You will be required to demonstrate that your code compiles and runs on GL using the specific Unix command string given for each project. Failure to do so means your project will not run with the grading scripts and will incur severe penalties.
Unless specifically required to do so, your code should not generate any output to the console as this may interfere with the grading scripts. You must remove or comment out all debugging output from your program prior to submission.
- Design: A good score on design depends on how well you have chosen several aspects of your program, including (but not limited to): object-oriented design and top-down design. For example, for a project where you define the classes, you will be graded on your choice of member functions and data members.
- Efficiency: your implementation of the project must have running times that conform to the project specifications. A slow function that produces the specified output is not a good implementation and will receive a poor score.
- Conformity: (such a nasty word!) your code must follow the class coding standards in spirit. These coding standards have been rewritten to focus on intent rather than rigid guidelines. You must have adequate documentation. If you turn in ugly unreadable code, there will be deductions.
Project Grade Changes
Project grade changes are unusual.
If you believe that a grading error has been made on your project, you should approach one of the TAs with your concern. You must be prepared to show the TA evidence of the specific mistake. You must make your request within 7 days of receipt of your grade.
Please check your program on GL using the test cases used for grading before you ask for a grade change. Test cases used for grading will be released after the projects have been graded.
Examples of valid grade change requests:
- Addition error in the computation of your score.
- The grade sheet says a file was not submitted, but it actually was.
- The grader forgot to run a test case and deducted points.
Examples of invalid grade change requests:
- You think 10 points is too much to take off for a particular mistake. (The answer will be: "We took off 10 points from every student who made this mistake. It will be unfair to change your score.")
- Your program runs on your own PC/Mac, but you did not compile it with g++ on GL as required.
- Your program works when you run it on your own test cases, but not on the test cases used for grading. (Thorough testing is the programmer's responsibility. You should have found those bugs yourself with robust test cases.)
Your instructor is the final arbiter for your project grade. If you have spoken with a TA and believe that you were treated unfairly (this would be very unusual), see your instructor.
Final Words
If you cannot complete a project, do submit whatever you have completed for partial credit. Projects that do not compile or do not execute will be graded on effort. In these cases, the grader will make a judgment call and estimate the amount of additional work that would be required to complete the project.