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.
- 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 there is an error in the grading of your project, please contact one of the TAs in person during their office hours. Do not ask about regrades by email. You must make your regrade request within seven days of the receipt of your project grade.
Regrade requests must be made to a TA in-person during their office hours within seven days of receiving the project 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, you think something is wrong with g++ on GL. (You have to test your program with g++ on GL.)
- 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.
Non-Working Projects
If you are unable to complete a project, it is usually worth submitting whatever work you have done. Partial credit may be granted for projects that do not compile or execute. In these cases, the grader will estimate the amount of additional work that would be required to complete the project and assign a score.