To simplify my life (and ultimately yours as well) I have adopted specific guidelines regarding how I want work submitted. By adhering to these guidelines you will make it less likely that I will lose your work or otherwise fail to process it correctly.
My preference is for you to submit your work electronically via Canvas. Email submissions are also accepted, but are discouraged. It is very important that you adhere to these guidelines for electronic submissions! I may process electronic submissions semi-automatically, and if you don't adhere to these guidelines your work might get deleted or ignored.
Program listings should have lines limited to 96 characters in length and contain no tab characters. Tabs tend to cause formatting problems when program text is displayed on a different system from where it was created.
If your submission consists of a single file (for example a lab report in .pdf format), name that file using the first letter of your first name followed by your last name. For example: pchapin.pdf. In some cases I may override this requirement but use this naming convention by default.
If your submission consists of multiple files, create a zip archive or a tar.gz archive containing those files. Be sure to include subfolders as appropriate. For example:
> zip -r pchapin.zip hw01
or
$ tar cf - hw01 | gzip %gt; pchapin.tar.gz
The above examples archive a folder named hw01 into an archive file. The examples use my name for the archive file, but you should use your own name.
I can accept other archive formats besides .zip or .tar.gz, but if you are using an "exotic" format or one tied to a particular environment (e.g., MacOS), you should talk to me first so I can verify my ability to read your submissions.
Although not necessary, I encourage you to also use GPG to digitally sign the file and even encrypt the file so that only I can read it. (my GPG public key). Building skills with this kind of technology is useful, but don't waste too much time trying to make it work unless you have a particular interest in security issues (or unless I specifically require it, of course).
Submit your file via Canvas (preferred) or email your file to me as an attachment (discouraged, but acceptable). In the subject line of your email message, mention the name of the assignment. Do not mail multiple assignments in a single message! Instead use separate messages for each assignment.
Be aware also, that the VTC mail system will silently discard archive attachments that contain executable code (including batch files). To work around that you can first be sure to clean out any executables before making the archive, or you can use GPG to encrypt the archive before mailing it.
Issues of document format compatibility cause any number of problems for people exchanging electronic documents. The obvious solution is to just standardize on a single format for document exchange. I'm not fond of this solution because it limits your ability to explore different software products to produce your work. For this reason I favor PDF format for document submissions. You can create a PDF file from any program that allows you to print documents by first installing a PDF printer (several free ones are available).
I will accept the following electronic formats in descending order of desirability.
Again: PDF is the best format overall. It can encode documents of arbitrary complexity in a portable way and eliminates problems that might occur with your documents being interpreted incorrectly by my installed applications. It also allows you to use any authoring tool you want; once the PDF is created it no longer matters how you wrote the original document.
In recent years I rarely require or expect paper submissions. In cases where you have a choice, please submit your materials electronically.
In some (very rare) cases I may ask you to submit printed copies of program source files or other plain text documents that you have produced. Please follow the guidelines below when you print out such files for submission.
Print program source files with a constant width font. Do not use a variable width font. Variable width fonts are suitable for papers and other documents containing prose. They are not suitable for program source files where, in many cases, the alignment of characters from one line to the next must be preserved.
Do not let the printed text overlap the ends of the pages. Use a suitable program to format the output so that there is a top and bottom margin on each page. Adding page numbers to each page is nice too, but not absolutely necessary.
Do not let any of the lines wrap or get truncated at the right edge of the paper. Wrapping destroys the appearance of the code and truncation throws away information. You may have to actively keep the lines in your file short to make this possible. I recommend restricting line lengths to 96 characters for maximum portability. In any case do not use an tiny font just to squeeze a very long line onto the page without wrapping; reformat your code instead.
Use a reasonable left margin (1 inch is reasonable) so that all the information can be read even if several pages are bound together. I suggest using an appropriate right margin as well, although it can be narrower.
Staple the pages together with a staple in the upper left corner of the pages. Do not bind pages together with a paper clip. (If your program listing is part of a larger report, it can be bound with the rest of the report).
Print on one side of the page. I find it awkward to write comments on paper that has been printed on both sides.
Whenever you submit a document, either printed or electronically, be sure it has a header that contains at least the following three items: Your name, a title of the document (file name, assignment number, etc. as appropriate), and the date of submission. Most files, particular programs, should also have a summary of their contents in their header. In non-program documents, this summary is often called an abstract.
When you submit a program, never fail to add comments to your work. Uncommented programs are incomplete.
When you submit a program, try to make sure it will at least compile. You might get significant part credit for a program even if it doesn't meet all the requirements. However, if your program won't compile, it can't be tested, and you will not get any credit on its functional aspects.
Make some effort to get spelling and grammar correct in all your writing, including program comments. I know that I'm not teaching English courses, but poor English does reflect badly on what might be technically excellent work. I'm not the only person you'll meet who will have this reaction. Although I probably won't mark down a great deal for spelling and grammar mistakes (my own spelling and grammar could use improving!), I do reserve the right to do so.
Remember: the intent of all of this is to help you produce a piece of work you can feel proud of, to give you practice producing work that will meet acceptability standards future employers may have, and to make my life easier when I look over your work.
Last Revised: 2023-01-10
© Copyright 2023 by Peter C. Chapin <pchapin@vtc.edu>