Grading Policies

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.


  1. Scoring Basics
  2. Scoring Details
  3. Project Feedback
  4. Grade Disputes

Scoring Basics

Most of the projects in this course will be worth between 30-50 points each, totaling to 40% of your course grade. Each project will be scored on the following criteria:
  1. Following the coding standard
  2. A functioning makefile (once we start using them)
  3. Program correctness
  4. Output formatting (if applicable)
  5. Testing code (if applicable)

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.

Coding Standard

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.


Program Correctness

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.

Output Formatting

For category (4), program output must always:

  1. Follow the project specifications
  2. Display correctly in an 80 character wide terminal
  3. Be labeled and formatted so that it is:
    1. easily readable, and
    2. understandable to a reader who has not seen the source code

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.

Testing Code

For category (5), testing code (usually a "driver" module) must always:

  1. Test all functions and logic paths in the main code
  2. Test all reasonable categories of input
  3. Test all typical special cases

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.

Scoring Details

Partial Credit

There are two kinds of partial credit you can receive for each project specification:
  1. Partial credit for components that partially meet project specifications
  2. Partial credit for components that do not the project specifications, but would if it weren't for a small programming mistake.

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:

  1. If your testing code is poor or non-existent, or it is otherwise obvious that you did not test your code properly
  2. If your code is poorly formatted and/or poorly documented, making it unnecessarily difficult for me to interpret it

Interdependent Code

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.

Broken Projects

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.

Additional Penalties

I may deduct additional points for programs that show truly horrible design decisions, for example:


Occasionally, I may decide not to deduct points for some particular issue, usually when I think something in the instructions was unclear. In this case, I will generally write "-0" followed by a comment on the relevant section of the affected score sheets.

Project Feedback

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.

Grade Disputes

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.

See Also

Last updated 1/15/13