If your program meets the project specifications and follows the coding standard, it's unlikely that you will lose more than a couple points for random mistakes and oversights. Nonetheless, I know I appreciate hearing this kind of stuff up front, so I will try to be explicit as possible about how your projects will be scored.
Much of the information in this document is course-wide policy. I will
expand on what I think are the most important points, as well as specify
as clearly as possible what my policies are on some particular problems.
Just writing the code in and of itself does not earn you any points. If
your code does not compile, or crashes before producing any viable
output, you can only receive credit for categories (1) and (2). See
Broken Projects for details.
Category (1) will be graded by deduction. For each criteria of the coding
standard that the program fails to meet, I will deduct points until none
remain for the category. In other words, you can meet several of the
criteria while receiving a score of 0 if, for example, if your code is
completely unindented, has no comments, etc.
The coding standard boils down to (a) formatting and (b) documentation. These are basic programming skills, and our requirements are not complicated, so there is no excuse for not following the coding standard.
In particular, please use the suggested format for file/function headers
unless you have an alternative that is equal or superior to ours.
If your makefile works and follows the course standard, you get full
credit for category (2). The makefiles for the projects in this course
will be almost identical, so this one should be a freebie.
Notes:
For full credit in category (3), your program must meet all of the project specifications. Within category (3), each specification will be graded independently (to the extent that this is possible), so you can earn full, partial, or no credit for each specification.
You need to test your programs thoroughly in order to ensure that they
produce good output for all normal input. You also need to include error
handling code to prevent special cases from crashing the program or
producing garbage output.
See below for the policy on partial credit.
For category (4), program output must always:
I would like to give special emphasis to the last point. You may know
what your unlabeled output means, but your user doesn't, and it's not
their job to figure it out.
For category (5), testing code (usually a "driver" module) must always:
Your testing code should change as you develop your program. Remove any unnecessary tests at the end, but leave in enough to prove that you tested thoroughly. Comment out any tests that crash the program.
For category (1), points will be assigned based on the degree to which
the component meets project specifications. Failure to handle special
cases will lose you fewer points than bad output for more typical input.
For category (2), you must understand that I am not obligated to try to find your mistakes in order to give you partial credit for program components that do not work properly. That being said, I will usually try to do so for your benefit. Because of this, it's in your best interest to make your code as readable as possible.
In general, small problems will result in 0.5 to 1 point deductions, and larger problems will result in the loss of a proportion of the total points for the category.
There are two specific situations in which I definitely will not search for your mistakes:
Often, a problem in one component of the program will ruin otherwise correct output from other components of the program. Sometimes, the effects of this are transparent enough that I can give you full credit for the dependent components without any trouble.
However, when this is not the case, I am not obligated to try to "fix" your code and rerun our tests in order to give the the maximum possible score for the dependent components. I may choose to do so if I believe it is warranted and easy to do so, but it your responsibility to identify the most core components of your program and make sure they work.
Per course-wide policy, if you turn in code that does not compile, or crashes before producing any viable output, you can receive points only for the "general requirements" criteria. In other words, you get a zero for all project specifications. It is not possible for me to accurately grade projects that do not run, so this is non-negotiable.
In practice, there is no reason for this to ever happen. One of the goals
of this course is for you to learn proper software development strategy,
the heart of which is incremental development. Please see Software
Development Pointers for details.
I may deduct additional points for programs that show truly horrible design decisions, for example:
For each project, you will receive a scoresheet with comments via email.
I take these very seriously, and would appreciate it if you do as well. I
will give very detailed comments for the first couple projects in in order
to help you master C++ more quickly.
Scoresheets will usually be returned within one week of the project due
date, and almost always before the next project. If you believe there is a
problem with a scoresheet, please email me ASAP. If I made a mistake, I
will fix it and update your grade.
I try to grade as accurately and consistently as possible, but if you believe I have (1) made a mistake, or (2) graded one of your projects unfairly compared to other students in this section, I will take another look.
However, I have no control over how the other TAs grade their students, so I will not consider complaints along the line of "so-and-so didn't take off points for [insert problem here]". In other words, all grading decisions are final for the current project. You can still let me know about these kinds of issues, but any changes I make will only affect future projects.
If you believe that grading between the TAs is unequal in general, you should inform Mr. McCullen directly.