CSC270H1Y - Summer 2001

How to prepare your assignments for submission

Assignments are always due at 6:00 p.m. on the due date, both for paper submission and for electronic submission. A submission at 6:01 p.m. is considered late.

Electronic Submission

Part -- sometimes all -- of each assignment or exercise will be submitted electronically. Typically, you will submit the program source files (the code that you wrote) on-line, and if requested, you will submit a written report on paper. We will print your source files for your tutor to mark, and we may also run some test cases automatically. Similarity checks ("MOSSing") will also be done in this way.

This should benefit the course as a whole: your tutor and -- believe it or not -- you too. Your tutor will have less administrative work to do in marking, and you will have less paper to drag around, a higher probability of knowing what really happened to your work, and a lower probability of competing with others who are copying their work.

However, to ensure that you receive a benefit rather than a penalty from e-submission, you need to ensure that your work really is submitted properly and that it looks right when it gets to your tutor. The rules in the next section are intended as a guide to submitting successfully, and submitting a program that looks right.

Please also be sure to read the assignment guides on the assignment page. These guides will help you format your assignments correctly.

Rules for electronic submission

These rules may be overridden for particular assignments. Any such changes will be announced in class and on the web site.

A: How to submit

  1. Electronic submission must be carried out with the submit command from your user account on CDF, with arguments -N Az csc270h, where z is the number of the assignment. This will automatically copy your files into the correct submission directory (/u/csc270h/submit/xxxxxxxx/Az/, where `xxxxxxxx' is your login ID, and `z' is the number of the assignment). You will be submitting a total of five assignments and their names will be A0, A1, A2, A3 and A4.
    For example, if you were submitting Project 3, the correct command would be 
    submit -N A3 csc270h filenames
    where "filenames" is the list of source files you want to submit, separated by spaces.
    Submit only SOURCE files, not compiled code. Do not put your files in subdirectories that you create.
  2. Capitalization matters in filenames just as it does in C and C++ programs. Name your files exactly as required by handouts and starter code.
  3. If you do not follow rules 1 and 2, our automarking program will not be able to find your assignment. Therefore, if you violate either of them you will be given a zero. The submit routine should prevent you from submitting an incorrectly named file.
  4. If you resubmit a file, that is the only copy we will have. Your old submission will be overwritten, including the timestamp, which means that we will have no way of verifying that you submitted on time.
  5. It's okay to submit extra files as long as all files are in the CORRECT directory. We will ignore all files that we didn't ask for.
  6. Paper submissions are not considered to have been received until the physical paper has arrived in the class drop box. Fax, e-mail, FTP, hand-submitted disk, or other electronic submissions will not be accepted.
  7. Be certain to include a comment at the top of each file which includes the file name, your name, your student number, your class section (Day or Evening), and your tutor's name.

You can find instructions for submitting electronically by typing man submit on any CDF workstation. To submit from home, you will have to learn how to use FTP to transfer your files to your CDF account, and then log in to CDF remotely to run the "submit" command. You can find more information on this process by clicking on "Working at Home" from the CDF homepage.

It is not possible to submit files directly into the submission directory by FTP. You must first transfer the files to your user account, and then run the submit command from your account.

B: How to make your program look right

In addition to following the style guidelines, you should obey these rules.

  1. Each line should be not more than 80 characters long, after tabs have been expanded. (If you're unsure about how tabs work, please read the section "Tabs" below.) We will use a tab width of 4 when expanding your code. Lines longer than 80 characters are not completely illegal, but your tutor is entitled to disagree with your judgement about over-long lines.
  2. If your editor doesn't display the line width, you can always make a line of 80 characters and paste it in to check whether you've gone over. Here is a line containing exactly 80 non-blank characters that you can copy and paste into your file: 
    /******************************************************************************/
    Make sure to align it at the left margin.
  3. Beware of "soft returns" -- some word processors, like WordPad, wrap lines automatically. If you use such a program, make sure that you press the return key yourself.

Tabs

(Skip this section if you know how tabs work. Come back to it if you have trouble.)

Tab characters are your friends, if you use them right. If not, they can make your work look really terrible.

A tab character is like a blank or space character in that it causes the following character to be shifted to the right, leaving empty space on the screen or the page. Unlike a blank, however, a tab causes a shift to a location that may be more than one character position to the right.

The usual problem that arises with tabs is that a program that "looks right" when you're entering it doesn't "look right" when someone else displays it. If the someone else is your tutor, that means lost marks, so you want to ensure that what the tutor sees is what you saw, or something equivalently acceptable.

The difference in the appearance of your code arises because your display mechanism (let's call it a "printer") and the tutor's printer use different interpretations of tabs. When a printer is asked to display a tab character, it skips to the next "tab stop". In general, there can be tab stops at arbitrary positions on the display line, but almost always the tab stops are at multiples of some "tab width", commonly 8 but often changed to a smaller value such as 4 for displaying program code.

Automatic indentation, of the kind provided in most IDEs and in editors like vi (and others that I'm sure are equally admirable) may use either tabs or spaces for indenting. The indenting width is usually configurable, and you can often configure whether tabs or spaces are used for indenting. As long as you always use tabs, or always use spaces, your programs will look OK. If you use tabs and the tab width is too large, it will be harder to read your program, but it will be indented in correctly -- that is, in a way that shows the program structure.

Problems arise when you mix tabs and spaces. This can happen because you forget or change what you're doing, or because your editor likes to mix them. Sometimes, for example, an editor told to use an indent of 4 will use a tab width of 8, with 4 spaces used when an odd multiple of 4 is needed. This means trouble when the program is displayed by someone using a tab width of 4.

So: pick a tab width. Use either tabs or spaces, but not both, to indent your code. Make sure your editor isn't sneakily mixing tabs and spaces.

How to look at exactly what's in your file

Click here to go back to the menu, if your browser does not support frames.