Guidelines for Grading Spring 2004 CS70 Assignments

The homework assignments are a major part of this class. If you do well on the homework, you will probably do well on the exams and thus will get a good grade.

To protect you against having a bad day, the lowest non-NC grade from your submitted homework will be thrown out. This does not mean that you can skip a homework, or submit an empty file. If you don't at least make a good-faith attempt, you will get an NC (no credit) that will count in your final grade.

How to Get an "F" in CS70

Getting an "A" is easy in any course: you simply do all the work correctly, on time, according to specification, with good style, without bugs, and really well. :-)

Getting a good grade in CS70 will require a lot of work. But to help you avoid the pitfalls, here is a short list of things that you should strenuously avoid:

The above list summarizes the worst things you can do, but doesn't give many hints on how to avoid them. We have found that most people who have difficulty with CS70 make the same mistakes. Here are some things that have traditionally caused people to get into serious trouble in CS70:


At the beginning of grading, a program has 150 points. When we grade programs, we look for problems and deduct points for flaws. Sometimes we also look for specific good things and add points for those. We do it this way to ease our workload: most programs have relatively few flaws, so it saves the graders a lot of time if they look for the problems rather than starting at zero and adding points for all the good parts. The end result is the same, however.

Programming is a lot like Olympic ice skating, where performances are judged on both technical merit and artistic style. In CS70, up to 90 points on your program will reflect your programming style and documentation (artistic style); 60 will reflect functionality (technical merit). In other words, if you have a choice between fixing a bug and fixing the style, fix the style first.

We do not give negative scores on the assignments. You cannot lose more than 60 points for functionality failures, nor more than 90 for style and documentation.

Code or documentation that does not meet minimum specifications (e.g., does not compile, is seriously deficient in comments, or has a missing README) will receive a zero for that portion of the score. It is your responsibility to make sure that your program compiles and runs on Turing.

Late Submissions

Since we use an automated procedure to determine submission time, if you submit even slightly after the due time, it will be recorded as being submitted the next day. However, there is a built-in automatic one day extension available on each assignment. The automatic extension always applies and does not require you to do anything special.

Be aware, however that

  1. Expert help (both tutors and instructors) may dry up after the (non-extended) due date.
  2. Having a "record of steady submissions" requires submitting substantial work prior to the (non-extended) due date. Work submitted during the automatic one-day extension period will never improve your steady-submissions record.

After the built-in extension expires, you must notify us when you make your final submission or you will receive no credit. Assuming you notify us properly, a late (post-extension) code submission will receive an immediate penalty of 10%; a late README will get a penalty of 5%.

The penalty for being late increases steadily over time. The rules are:

  1. As mentioned above, a penalty of 10% of your points (5% for the README) will be applied the instant the deadline passes.
  2. The penalty continues to increase at a rate of 10% every 15 hours (5% every 15 hours for the README).
  3. To keep you from skipping other classes, the penalty does not increase during class hours, i.e., 8 to 5 weekdays.
  4. The net result of the above three rules is that you start with a 10% penalty (5% for the README), which increases another 10% (5%) for each day you are late. Turning in your work exactly 24 hours late will cost you 20% (10%) of your points.
  5. If the assignment required turning in pseudocode before final code, and your pseudocode arrived on time, the late penalty will be multiplied by 0.7. "On time" means by the official due date (i.e., not during the free one-day extension).
  6. If you have a record of steady submissions for the assignment, the penalty will be multiplied by 0.7. However, this rule will only apply if it is clear that you began work at least two days before the non-extended due date. The reason is that the point of the rule is to encourage you to start before the last minute.

Summary of Grading Guidelines

Here is a (non-exhaustive) list of things the graders are taking off points for, along with a list of associated maximum penalties. Refer also to the homework policies page for information on homework.

Notice that a maximum penalty of (say) -20 means that we will deduct between 0 and 20 points for flaws of that type, depending on the severity of what's wrong with your submission, how much you were expected to know, and various other factors.

The guidelines below are guidelines, not a contract. The grading rules change depending on the assignment. The numbers below are intended to give you the flavor of what is going on. In particular, we are often nicer than implied below.

General Issues


The README file is critical! Don't forget to run it through ispell before you submit it.

Style/Commenting Issues

Style matters!

The following (and similar) major defects will automatically give you a zero for your style grade.

Other style issues to watch out for:


Remember that it will cost you a lot of points if you submit code that doesn't compile for trivial reasons. So after you've finished your final edit, compile with g++ -Wall -pedantic before submitting the file. If you really can't submit a working program, document what the errors are (in README, that's what its there for) and submit what you have. If you document a bug in the README, you will usually lose only half the points listed below (the exception is when you clearly didn't make an effort, as for example a program that doesn't even come close to compiling).

The following (and similar) major defects will result in a zero for the functionality grade.

Other functionality issues to watch out for:

© 2004, Geoff Kuenning

This page is maintained by Geoff Kuenning.