See also the homework grading page for information on grading.
Announcements will be distributed using the mailing list email@example.com. It is your responsibility to confirm that you are on this list. (If you don't know how to do this, send mail containing the single word "help" to firstname.lastname@example.org.)
Homework grades and the like will be mailed to your Turing account.
It is your responsibility to check your Turing mailbox regularly. If
you typically read your mail on some other machine, we strongly advise
you to put a
.forward file in your Turing account, so
that mail will be forwarded to your usual mailbox.
All homework must be submitted on Turing using the
cs70submitallprogram. You may
develop your code on any
system you choose, but we will be testing it on Turing using the
g++ compiler, and it is your responsibility to ensure
that it will run on that computer using
g++ -Wall -pedantic. Each
assignment will require you to submit two or more files with specified
names. One of these files will always be named README, and will
contain the English-language documentation for the program. The other
file(s) will contain the program itself.
The README file will usually have a later deadline than the other
Unless otherwise specified, you must use the filenames
specified in the assignment, or
points will be deducted from your grade. The only variation allowed
is in file extensions: although the assignments will specify the
.cc extension (e.g.,
median.cc), we will
allow any extension accepted by
To paraphrase the late Mayor Richard Daley of Chicago,
submit early and often. Every
time you reach a milestone (header files completed, code written, code
compiles, something starts working even a little bit, etc.) or take a
cs70submitall to submit what you have so far.
Doing so has several advantages:
Late submissions will be penalized severely; see the homework grading page for more information. A submission that is even one second past the deadline, by Turing's clock, is considered late. We will make appropriate arrangements for extended or last-minute system crashes, bugs in assignments, vague or broken specifications, or other factors beyond everyone's control. Your responsibility is to inform the course staff promptly if you detect or suspect such a problem. If a problem emerges at the last minute so that we cannot correct it, clearly describe in your documentation the problem you encountered and what assumptions you made to work around it.
Full homework grading guidelines can be found on the homework grading Web page.
All of your submissions will be graded electronically. The graders
will insert commentary into your programs and README files regarding
good and bad aspects, errors found, things that don't work, etc. When
grading is complete, the graded files will be e-mailed back to your
Turing accounts. You will be able to find the grader's comments and
the scoring by searching for the string "
the quotes. This string will be used to mark all of the grader's
changes to your files.
If you have questions about the grading, please try to talk to the graders themselves first. If they cannot resolve your difficulty, feel free to ask your professor about the problem.
Code must be properly commented. The main idea is that the grader should be able to understand your code easily, not have to tear his hair out wondering what some statement is doing. The first time you have to deal with poorly commented code (if you haven't already), you will understand how annoying it is.
In particular, the top of each code file should contain your name, the course and assignment numbers, a brief summary of what's in the file, and any non-obvious details about how to compile and run the code. This might typically be 10-30 lines of text.
Line-by-line comments should be included as necessary to make the code easy to read. A clear coding style, together with informative variable and function names, will reduce the number of comments required. Obscure code or cryptic function names will cause loss of points (for bad style) and also require more extensive comments. We reserve the right to grade excessively impenetrable code as if it did not work.
The README file is one of the most important parts of the assignment. Its purpose is to document your program. The README file must be in plain ASCII text (not HTML or MS-Word format), and in it you must specify:
The description of how your code works will probably be brief (a few sentences) for the early assignments and get longer (e.g. several paragraphs) towards the end of the term. However, the descriptions must always be complete. The "general structure" section should describe the main functions and what they do, the key steps in the algorithm, and how your code is organized into functions.
The "files" section may be omitted if the program is contained in a
single file. Otherwise, it should briefly explain how the program is
organized into files. Files that "go together" (such as
cc files) should be discussed as a
group. The purpose of this section is to help the reader locate
various classes and functions, so the descriptions can usually be
The documentation should not contain more than very brief fragments of code or pseudocode. Concentrate on explaining the main features of the algorithm, as if to someone working on another system in another programming language.
Sometimes, students ask whether some particular item should be included in the README file. The general rule is, "if you're unsure, put it in." The graders do not normally deduct points for having excessive material in the README, but being too brief will often cost you.
To help you understand what a good README looks like, here are three sample files. All of the samples have been taken from the same homework assignment. All three earned top grades and illustrate different ways to approach writing a README. The first is very extensive. The second is shorter but still thorough and well organized (although the grader would have preferred to see some section headers). The last is less than a quarter the size of the first, yet still covers all the bases. It is a good example of how terseness can be sufficient.
Note that the deadline for submitting the README file is later than the deadline for the code. This is to encourage you to spend extra time on documentation, rather than spending your last few minutes frantically trying to fix bugs.
The README file should be written in your best English, using correct spelling and grammar. Do not write in all uppercase or all lowercase, both of which seriously harm readability. Write in complete sentences using proper punctuation.
One excellent way to be sure that your README file uses good English is to run it by the writing center.
Things to watch out for:
Some allowances will be made for special writing difficulties, such as dyslexia or English as a second language, but only if we are informed beforehand.
Make every effort to produce a readable program. See the C++ style hints for some general tips.
© 2001, Geoff Kuenning
This page is maintained by Geoff Kuenning.