Submission

Example:

Assignment 2 is due on Tuesday. Nancy Hacker wants to turn on the assignment on time, but she is not quite done. After reading the submission guidelines, she figures out that she has a free bonus day, so the assignment is really due on Wednesday. That is, if the TA has the assignment when he comes in that morning, she should be ok. The TA lives fast and wakes early, so she figures before lunch Wednesday she'll be fine, else she'll lose half of the points.

Nancy also understands that she has to prove that her program runs. Being a sensitive hacker that she is, she knows that she has to include sample output, AND she has to make it easy to read, otherwise the TA gets pissed off.

She sends in the assignment by email before NOON Wednesday and she puts the paper copy in the mailbox "Shamma" when she happens to be in the CS department.

The long version:

You should attach ONE document containing your entire assignment to the email. The document name should be Axlastname_firstinnitial and whatever extension is appropriate. x stands for assignment number. So, for assignment 3 I would send an email with the subject line "Assignment #3" containing the file A3krema_m.doc. 

Details:

• Your Code Must Be Properly Formatted -
  This course has no fixed coding standards; The TA will not grade for style except in egregious cases (see below).

  That said, programs are ultimately a medium of communication. Obviously, a program has to explain to the computer how to do a specific task. However, programs are also a way of communicating with other people. A program needs to express how it works to the person reading it well enough that they can safely and efficiently fix or extend it. In this class, the person reading it will most often be the TA, but in real life, it will be your coworkers, your boss, or even you yourself. (If you don't think that it should be hard to understand a program that you wrote yourself, try going back and reading your old A11 problem sets and see if you understand everything your old code was doing).

  For this reason, you should approach writing your program as you would writing an essay for a composition class: it should be clear, concise, and precise. Again, we have no fixed coding standards for the class. We will not make you fill in a specific boilerplate comment at the top of ever procedure, force you to comment every ')' or '}' with an annotation about what statement it is closing off, or make you start all of your integer variable names with "i" and all of your floating point variable names with "f", although we know people in industry who do all of the above. Instead, we have a simple rule for coding style:

  • It is your responsibility to make your code easily intelligible to the TA. For the kinds of programs we will write in this class, this will be easily accomplished simply by adding a moderate number of comments, by carefully choosing variable and procedure names, and following the style points mentioned here.

  Note that sometimes adding more comments makes a program less readable. If you find yourself commenting a line like

  (setf a (+ b c))

  with a comment like "set a to the sum of b and c", then you're going overboard.

  Generally, there are three types of comments:
  1. Comments which describe overall APIs, how is file/class/abstraction behaves.
  2. Comments which describe a tricky block of code which does something unexpected that you feel the need to describe because it isn't obvious.
  3. Comments that are worthless

  Finally, there are a few style issues that we will penalize you for:

  • Code that runs off the page or is too small to read.
  • Failing to indent the code, or indenting it inconsistently.
  • Egregious failure to abstract code, such as having a large number of almost identical procedures that could have been implemented as a single procedure with an additional parameter.
  • Unecessary use of setf (this hurts you more than you know)
  
  
  
• Your Code Must Run -
  We will not accept broken code. If it doesn't run, don't turn it in.

• Tell Us What You Did
  Along with the code printout, submit a two sentence blurb: does it fulfill the assignment completely, partially, or not at all. If you didn't finish the assignment, why?
  
  

• Tell Us Who You Worked With
  If you worked with someone, say so. Tell us if you helped them, or they helped you. Be specific about what you worked on together. Copying someone's code verbatum and putting their name on your paper will NOT be acceptable.

• SENDING CODE IN EMAIL
  
  
  • Send it to ayman • cs northwestern edu
  • Send the code in an attatchment. DO NOT PASTE THE PROGRAM INTO YOUR EMAIL. You must send it as an actual attachment  
  • DO NOT SEND ME CODE IN A WORD DOCUMENT!
  • DO NOT SEND ME CODE IN A WORD DOCUMENT!
  • DO NOT SEND ME CODE IN A WORD DOCUMENT!
  • The filename of the attachment should be : AXlastname_firstinitial 
    
    
  • Title the email: assignment#X

   

  • Include your comments before the code
    
    
  • Include ALL OUTPUT as commented text (each line preceeded by a pair of SEMICOLONS). Output should directly follow the code

    (defun my_ai_program (args)
      (let ((foo))
        (do some amazing stuff
         ...
         ...
         ...
        )
      (return the_right_stuff)))
    
    ;; program call and input here
    ;; output here - after the program!!
    

   

  In addition to these guidelines, you need to follow the guidelines for each assignment.