Guidelines for Grading Fall 2002 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:

• 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 function 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 listened.

General

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. 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 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.

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

• 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 listed here.

Documentation

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 ispell: -2 each, up to a maximum of -20 points
• Grossly ungrammatical sentences in documentation: -2 each
• 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

Style/Commenting Issues

Style matters!

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
• Forward goto, other than for multilevel breaks
• Backward goto
• Extensive use of global variables
• Extensive use of the C preprocessor's #define 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 -10 points.
• Commenting issues:
  • Inadequate comments: -20
  • Absence of standard file header (author, date, file name, description): -5
  • 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
  • Using *new or delete &: -20
  • Unnecessary use of the C preprocessor's #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 constants)
  • 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 "myvalue)": -15 (per assignment)
  • 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 NULL 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

Functionality

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 format: -50
  • Arbitrary limits on input size, unless explicitly allowed by assignment: -25
  • 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 operators: -15

© 2002, Geoff Kuenning

This page is maintained by Geoff Kuenning.