CMSC 341 - Project Grading
Student Acknowledgment Statement
By enrolling in this course (CMSC 341) you acknowledge the following:
"I have read, understood, and agree to abide by all the policies, procedures, and expectations outlined in the course syllabus and related materials including this website. I understand that it is my responsibility to stay informed of any updates and to seek clarification from the instructor if needed."
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. 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. We will run your project with large data sets. An efficient implementation runs in a matter of milliseconds.
- 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.
The weight given to these criteria may differ from project to project.
Unauthorized Coding Styles
The use of the following constructs causes corresponding deductions:
- Every use of range based for loops in the project file and/or mytest.cpp incures 20 points deduction.
- Every use of auto type in the project file and/or mytest.cpp incures 20 points deduction.
- Every use of size_t type in the project file and/or mytest.cpp incures 20 points deduction.
- Every use of bitwise operators in the project file and/or mytest.cpp incures 20 points deduction.
- Any use of lambda functions (expressions) in the project file incures 30 points deduction.
- Any use of lambda functions (expressions) in the test file (mytest.cpp) incures 30 points deduction.
- Including libraries functional, cassert, assert in the project file and/or mytest.cpp incures 30 points deduction.
- Including an unauthorized library in the project file (according to the project requirements) incures 30 points deductions.
- A test in mytest.cpp will not be accepted if it does not follow the project requirements for the size of testing data.
- A test in mytest.cpp will not be accepted if it does not follow the project requirements for the type of data, e.g. not using the provided Random class.
- There is 20 points deduction if the student tests are not called in mytest.cpp.
Grading Rubric
The following presents a general project rubric. It shows how a submitted project might lose points. The percentages are subject to change.
- Conforming to coding standards make about 10% of the grade.
- Your test program is worth 50%. If you submit the sample driver program as your test program or no test program is submitted there will be 50% deduction.
- Correctness and completeness of your test cases (mytest.cpp) make about 30% of the grade.
- We have written test cases to test your submission without knowing anything about your code. Therefore, it is extremely important that your submission conforms to the specified requirements. Passing tests make about 30% to 40% of the grade.
- There will be deductions if we need to clean up your shared folder. One can find a non-exhaustive list of problems that cause deductions at the submission page.
Non-Working Projects
A project might not work due to different reasons. The following list presents some possible reasons. Please note, the list is not exhaustive. There might be other reasons too. If a project does not compile/run for any reason it will be treated as a non-working project. Such a project will never receive full score.
- 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.
- The files submitted are renamed. For example, you submit myTest.cpp instead of mytest.cpp. Linux file names are case sensitive. This problem incures 20 points deduction.
- You submit the project files in sub-directories. This problem incures 20 points deduction.
- You include a .cpp file in your project instead of a .h file. This problem incures 20 points deduction.
Project Grade Changes
For quality control purposes and in order to ensure the grading process is a fair process to all students we will re-check some submissions throughout the semester. This might result in increasing or decreasing a grade. For example, we might detect the use of AI generated code by the end of semester in an early submission; this will result in deductions or even treating the submission as an Academic Integrity Violation case. Please check the possible outcomes of an Academic Integrity Violation at Academic Conduct Policy.
Project Grade Disputes
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. Please check your program on GL using any provided test cases before requesting a grade change.
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.)