Guidelines for Grading Spring 2001 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
- Not turning in a homework assignment. Missing assignments
and assignments that are obviously not a good-faith effort
are weighted very
severely in the final equation.
- Not completing any exam.
- Being consistently late on assignments. (Watch out! It's
easy to fall into this trap late in the term.)
- Turning in working but sloppy code. Style counts for more
than half your points.
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:
- Starting assignments late. This is the
number-one CS70 mistake. 9 times out of 10, the people who
finish late, or who never get their program working at all,
are the same ones who didn't get started until the day the
assignment was due. If you want to have a fair chance, you
should begin work over the weekend. That way, if you have
difficulty you'll have plenty of time to ask for help.
- Not asking for help. Over and over again,
we receive README files with sentences like "It segfaults in
foo, but I couldn't figure out why."
Invariably, these assignments are submitted by people who have
never shown up for office hours, and who never come to see the
tutors. We are paid to help you. Make us earn our keep!
- Getting help from unqualified people. It's
fine to ask friends to help you. But sometimes we find that
students who are having trouble ask for help from people who
didn't do all that well in CS70 themselves. The result is a
lot of wasted time.
depending on a friend,
- Skipping assigned reading. The assigned
reading covers much more than what we have time for in class.
Even if you don't retain everything you read, you'll at least
have an idea where stuff is. Then, when you run into problems
(or are taking an exam) you can look it up.
- Not participating in class. Class attendance
is your business. However, there is a clear correlation
between participation and performance. People who skip class,
those who don't ask questions when a point is unclear, and
those who don't pay attention also tend to be the ones who get
low grades. There are exceptions to this rule, but it should
be pretty obvious. If things are unclear, if you have pointer
problems, and if you have trouble getting your assignments to
compile, then you should be coming to class and getting involved.
- Ignoring our advice. Sometimes we will tell
you that there are multiple ways to do things, but one way is
preferred. There are usually reasons for preferring a
particular, but we don't always have time to explain them in
detail. However, if you insist on choosing a non-preferred
approach, you are very likely to discover the reasons the hard
way, and waste valuable time learning that you should have
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 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.
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
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
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
- Expert help (both tutors and instructors) may dry up after the
(non-extended) due date.
- Having a "record
of steady submissions"
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,
a late 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:
- As mentioned above,
a penalty of 10% of your points (5% for the README) will be
applied the instant the deadline passes.
- The penalty continues to increase at a rate of 10% every
15 hours (5% every 15 hours for the README).
- To keep you from skipping other classes, the penalty does
not increase during class hours, i.e., 8 to 5 weekdays.
- 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.
- 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
- If you have a record of
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
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.
- Incorrectly submitted files (mostly this means
wrong file names) (-10). This does not include extraneous
files. There is no penalty for extraneous files, since
cs70submitall is rather over-eager about grabbing stuff.
- There will also usually be assignment-specific issues not
The README file is critical! Don't forget to run it through
ispell before you submit it.
- Missing README: -60
- README doesn't describe program's purpose: -10
- README doesn't describe input/output format: -5
- README doesn't describe restrictions, limitations, and bugs,
or state that there are none: -5
- README doesn't describe algorithm: -15
- README doesn't describe data structures: -10
- README doesn't adequately document the general structure of
the program: -5
- Misspellings found by
each, up to a maximum of -20 points
- Grossly ungrammatical sentences in documentation: -2
- Unreadable documentation, such as very confusing writing: -5
- Generally sloppy formatting, such as using only one case,
all text in one paragraph, etc.: -10
- Double-spaced README (this isn't a humanities course): -1
The following (and similar) major defects will automatically give you
a zero for your style grade.
- Seriously misaligned code (improper or inconsistent indentation)
- No comments or grossly insufficient comments
goto, other than for multilevel breaks
- Extensive use of global variables
- Extensive use of the C preprocessor's
feature, other than for header-file bracketing
Other style issues to watch out for:
- Lines over 80 characters wide in any file,
including README: -2 each, to a maximum of
- Commenting issues:
- Inadequate comments: -20
- Absence of standard file header (author, date, file name,
- Comments in all caps: -5 (all lowercase is
acceptable, though only barely)
- Line comments not vertically aligned: -5
- Comments that merely restate the code, as in "test for x
equal to 1" on an if statement, instead of explaining
why something is done: -10
- Multi-sentence comments in which the sentences don't
start with a capital and end with a period: -3
- Frivolous comments that distract from readability: -3
- Formatting issues:
- No whitespace between code and comments: -5
- No blanks around operators: -5
- Generally sloppy formatting: -10
- Left-justified code inside functions: -5
- Minor problems with code alignment (e.g., improper or
inconsistent indentation): -3
- Inconsistent style (variations in capitalization or
blank usage, etc.): -5
- No blank lines, anywhere: -5
- Grossly excessive blank lines, so that code is
essentially double-spaced: -3
- C++-specific issues:
- Not using colon notation in constructors: -10
- Failing to either define or disable copy constructors
and assignment operators: -20
- Unnecessary use of the C
#define feature: -10
- Code-quality issues:
- Using a clumsy approach, such as an unnecessary loop or
if: -5 (per instance)
- Global variables: -10 (this does not apply to global
- Public data members: -10
- Making data members effectively public by providing
unnecessary accessors: -8
- Bad, frivolous, or non-mnemonic class, variable,
function, or file names (e.g.,
q" or "
- Wrapping a function in a class when it doesn't need one: -5
- "Upside-down" code (
main at the bottom of the
file, minor functions preceding more important ones): -10
- Poor choices for encapsulating functionality (e.g., a
function that does two fairly different things just because
your program needs them both at the same time): -10
- Inappropriate use of constants (0 for
NULL is OK, but
0 or 0x0 for
'\0' is not): -5
- "Magic" numbers (generally, though not always, defined as any
constant other than 0 or 1 that does not have a
meaningful symbolic name): -3 per instance to a
maximum of -15
- Using a null (zero-length) string when a
pointer would be more appropriate, or vice versa: -2
- Anything else that jumps out as particularly bad (i.e those
of you who think its cute to make social commentary in your
comments and names): -25
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.
- Won't compile
- Doesn't compile using the command specified in the assignment
- Doesn't terminate for many or all inputs
- Segmentation violations or bus errors on many or all inputs
- Won't accept input in anything vaguely resembling the specified format
- Major output differences from the specification
Other functionality issues to watch out for:
- Compilation issues:
- Generates compiler warnings: -10
- Makefile doesn't list dependencies properly: -5
- Execution issues:
- Doesn't terminate on a few inputs: -15
- Not checking arguments or argument counts (after
methods for doing this
have been introduced in class): -5
- Segmentation violations or bus errors: -30
- Fails to behave appropriately for arbitrary test
input (e.g., exits silently instead of printing an error
message), unless allowed by assignment: -20
- Inadequate error checking (e.g., doesn't crash but
produces nonsense results when given nonsense input): -10
- Obviously inefficient algorithms: -15
- I/O issues:
- Won't accept input in specified format: -15
- Won't accept input in anything vaguely resembling specified
- Arbitrary limits on input size, unless explicitly allowed by
- Generating output without a final newline: -5
- Minor output differences from the specification (e.g., excess
blank lines): -2 each, to a maximum of -20
- Output basically accurate but not in format specified
by assignment: -20
- Nasty bugs:
- Memory leaks: -10
- Returning dangling references from any function, especially
© 2001, Geoff Kuenning
This page is maintained by Geoff