CIS 352 – Homework Submission

General Logistics

• For each assignment, you must submit a hard copy of your work to the CIS 352 bin in CST 3-212. If your work includes multiple pages, make sure that they are stapled or clipped securely.

  This hard copy is the version of your assignment that gets graded; if you fail to turn it in, you will receive no credit for the assignment.

• You also need to submit code electronically.
  • To do this, just send an email message to with a subject line of just 352submission (no spaces) and add the files as attachments.
    
    
  • If your mailer doesn't do attachments, then just include all the files in your message with clear separations between them and with indications of the names of the files.
    
    
  • NOTE: Keep the files plain text. Do not send any MicroSoft Word files (they are huge!) or else the instructor will become very grumpy.
    
    
• There should be only one hard-copy and one electronic submission per group. Everyone in the group is equally responsible for making sure that the assignment is turned in on time and that all names appear on it.

• No late assignments will be accepted.

• Remember the course Honor Policy: give credit where due, and submit only your own work.

What to Turn In with Code

In addition to correctness, we expect the following (and may adjust your grade accordingly):

• Legible code.
  Use indentation and line breaks to make your code easier to read: doing so may help you in getting things to work, and it will certainly help us in grading. DrScheme provides support for indenting code: make use of it.

  We will take off points for bad formatting.

  Use comments to explain any portions of code that are not perfectly obvious.
  Hint: If you're in doubt, it's not perfectly obvious.

  Use a fixed-width font (e.g., courier) for printing out your code and transcripts.

• Contracts and purpose statements for all procedures that you are asked to write

  We will be following the approach of Felleisen, Findler, Flatt, and Krishnamurthi in their How to Design Programs book. Specifically, check out Section 2.5.

  At this point in time, you do not need to write contracts/purpose statements for any helper procedures you may write (although contracts are suggested). However, if it seems that people are running into lots of type problems later on, I will probably require contracts for ALL functions.

• Convincing test cases.

  You should provide enough test cases to convince us that your program works as necessary. You may use as test cases the examples that are given to help describe the program's behavior (you don't have to). However, they may not cover all potential cases: it is your responsibility to ensure that no cases are omitted.

  What if you don't include test runs?

  If you fail to include test runs for a given problem, it is very possible that you will receive no credit for that problem.

  What if you can't get your code to work?

  If you can't get your code to work correctly, you should still provide a relevant set of tests. Include comments explaining what works (backed up with test runs), what doesn't, and what you were trying to do.

  You will generally receive more credit for pointing out the situations where your code doesn't work than you will for trying to hide it.

  Why don't we just give you all the test cases?

  Being able to identify relevant test cases is an important skill that helps not only in verifying programs but also in designing them. You should start thinking about possible test cases before you write your programs, as they force you to think about the cases that you need to consider.

  What if you think the examples given in the original problem description are sufficient as test cases?

  Even if they do cover all necessary cases, you should include test cases of your own. Otherwise, you'll likely lose points.