CSE341 - Submission Guidelines, Summer 1999

(Adapted from guidelines by Craig Kaplan)

When you submit an assignment, please try to adhere to the following guidelines. Grading is already a lot of work, so please help out by presenting things to your TA in a manner that will make the paper shuffling easy. It will make your TA happy. And a happy TA is a high-grading TA.

Note that this list is not meant to be complete. It's the set of guidelines that I always wished I had to make submissions more consistent. I'll try to update the list when I come up with more stuff I'd like to see.

I'm sorry if this is a bit of a pain, but it really makes life easier for me. Thanks for sticking to these guidelines.

Name and Section
Put your name and section on everything you submit. Staple your papers or put them in a large envelope. Make sure to put your information at the top of the front page or the front of the envelope. If you're working a groups, put all of your names and section numbers on the submission.

For electronic submissions, put your information at the top of every file. If your file is a program, put it in a comment. If you were in a group, put all of your names in the files.

Number of Copies
You will submit most assignments both on paper and electronically unless otherwise instructed. We will expect that code you turn in on paper is identical to what you turn in electronically; otherwise, we won't know which to grade. If, during grading, we discover that your code printout(s) and electronic submission(s) are not identical, you will not receive credit for your work.

If you're working in a group, submit only one copy for the group. If you're submitting electronically, submit under only one user. If your names are in every file (see above) then I'll know to assign the grade to the whole group.

Deadlines
Unless otherwise stated, assignments are due at the start of class or section on the due date. This is also true for electronic submission. The time you submitted is recorded with your submission when you use the turnin command.

Using turnin
turnin is the command available on the instructional UNIX machines (e.g. orcas, sanjuan) for submitting things electronically. You can use it to turn in a single file, multiple files, or directories. Successive uses of turnin overwrite previous submissions, so you can fix things in your code (up until the due date, of course). For more information, consult the man page.

Testing output
The script command on the UNIX systems can be used to generate a transcript of a UNIX session that can then be edited for testing output. See the man page for more details.

When you submit testing output, please don't submit pages and pages of meaningless output. Submit only the parts of the testing output that show the interesting tests and their results. Your job is to convince the grader that your program works, not that you can produce lots of output with it.

Only code should be submitted electronically---no testing output. Testing output should be submitted on paper.

Comments
Your code should contain at least one comment, the one at the top of the file that says your name(s) and section(s). We do not require that you fill your file with meaningless comments at the start of functions, etc. The file containing your program should be clear and understandable enough that someone not familiar with it (e.g., the grader) can read it and see that you know what you are doing. Comments are just one way to achieve this readability.

CSE-341 Home Page


Greg J. Badros / U Washington Computer Science and Engineering / badros@cs.washington.edu