Homework Assignment Submission
CSC 207 Algorithms and Object Oriented Design Spring 2011


This course features several homework assignments, as listed on the assignments page.

Submitting Programs

Short version

Turn in electronic copies of all Java source files only. Turn in a paper version of these, sample output/test runs, and correctness essay.

Detailed version

In turning in any programs for the course, please follow these directions:

  1. The first seven or more lines of any Java file should be comments containing your name, the class section, an identification of assignment being solved, and a description of the contents of the file. For example (from Basics.java):
    * Jerod Weinman  
    * CSC 207.01
    * Assignment 1: Java Basics
    * Basics: Definitions of several basic functions for numerical predicates 
    * and some array operations.
  2. A comment is required for every definition of a Java method, stating in English what that program unit is supposed to do. Complete Javadoc-grade documentation is not necessary for every method, but is strongly encouraged.
  3. Obtain a nicely formatted listing of your source code using the enscript(1) command:

    enscript -Ejava -2 -r -p prettysource.ps Source.java ...
    where prettysource.ps is the name of the file in which you want the formatted source code stored (enscript(1) generates a PostScript file, hence the ".ps" extension.) If your work involves several Java files, list the primary program first, then list any supplementary files. Multiple source files can be placed in one call to enscript(1). You may also use a wildcard such as *.java. Be sure not to include any compiled class files.
  4. If you have multiple Java source files, create an archive of them for electronic submission. For example,

    tar cf sources.tar Source.java ...
    where sources.tar is the name of the archive file you want your program source files stored in. You may list as many source files on line as you wish, or even use a wildcard (*.java) You may also add an entire directory to an archive by including the directory name without a trailing "/" in the list of files. If you do this to include the entire directory, please be sure you do not include any class files, etc.
  5. Create a transcript of your program's compilation and testing/output runs using the script(1) command:

    1. In a terminal window, start recording output to a file called transcript with the command:

      script transcript
    2. Compile your classes with javac (or make or ant) as appropriate.
    3. Run your program with appropriate test cases to check its correctness. If all your tests do indeed pass, please use
      tester.Tester.runReport(obj, false, false);
      when generating output to save paper.
    4. Run your program with on any other demonstrations as necessary.
    5. When your runs are complete, stop the script session by typing Ctrl-D.
    6. Convert the recorded text file to a nice, printable PostScript file using enscript(1):

      enscript -2 -r -p transcript.ps transcript
      where transcript is the name of the recording file you created above, and the ".ps" file is the printable version enscript(1) creates.
  6. Concatenate and print your program listing and transcript, i.e.,

    cat prettysource.ps transcript.ps | lpr -Pprinter
    where printer is the name of the printer you want to send the output to.
  7. Include a separate essay that argues why your program is correct, based upon the evidence from your tests. No hand-written statements will be accepted.

    You may use a word processor or a simple text file. You may easily incorporate a text file into your submission by including it in the transcript. Between 5.d and 5.e,

    cat statement.txt

  8. You or one group member (if collaborative) should submit:

    1. your printed work at the beginning of class on the day it is due, AND
    2. an electronic version of the source file archive (source.tar from 4 above) online via PioneerWeb by the beginning of class.
    The late policy applies to both portions of the submission jointly (e.g., if one portion is late both are considered late.)

Notes on Grading


Every assignment requires a suite of comprehensive tests. After the first assignment, you will be expected to use formal unit tests. Hopefully your transcript will demonstrate the successful passing of your tests. In addition to this, your essay must argue why these tests demonstrate that your program is correct. Of course, since your tests are themselves, program code, they should include unit test "messages" or comments with an indication of what they are to accomplish. This practice can and should help you write your prose commentary statement.

At a minimum, your tests and the corresponding essay should include:

Requirements Summary

Since every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in Java format):

    if (  (no_comments)
       || (no_evidence_of_compilation)
       || (no_tests)
       || (no_commentary_on_correctness))
    return (no_grade);

When a program is submitted according to the format specified above, it should be understood that the transcript reflects a complete session of compilation and running of the accompanying source code. With this understanding, editing of any script file is strictly forbidden and raises questions of academic dishonesty. According to College policy, any evidence of academic dishonesty must be turned over to the Committee on Academic Standing for action.


Because code maintainability is an important part of development, your assignments will be graded in part on style, as well as correctness. After all, if I cannot understand your code (or it takes me too long to), I cannot give it a grade regarding its correctness.

Some style matters I care about that you may want to consider:

  1. Indentation/whitespace that helps delineate code blocks. (Most text editors will help you with this.)
  2. Helpful comments on blocks of code or particularly complicated expressions.
  3. Methods that are reasonably small. (A very good guideline I try to follow is getting an entire function to fit on one screen; this makes interpreting a function's action more readable by forcing you to break it down into named steps that can be seen at once. It also promotes easier debugging and unit testing.)
  4. Code lines that are no wider than 80 characters. This makes them easier to read both on screen and on paper. (See #1 in this list.)

Jerod Weinman
Created 19 June 2008
Revised 15 January 2009, 21 January 2010, 18 January 2011, 28 January 2011

Adapted from Assignments for Computer Science 213, Henry Walker; and CSC213, Fall 2006 : Laboratory exercises, Janet Davis.

With thanks to Henry Walker, Janet Davis, and Marge Coahran.