Homeworks and Grading

Each assignment will be given a letter grade based on the usual scale (A=4, B=3, etc.). Pluses and minuses are worth 0.3 (A- =3.7, B+ = 3.3, etc.), with the exception that an A+ (rarely given) will be worth 4.1. Final grades will be based on the weighted average of the assigned programming projects. Assignments will be weighted by the number of weeks given to complete them, so that two-week assignments will be counted as two one-week assignments. However, although four full weeks will be allotted for the final project, it will be weighted five times. There will be no exams, and grades will not be curved. In general, late assignments will not be accepted unless I am contacted before the assignment is due. I prefer assignments on 8.5 x 11 paper, with a single staple in the top left corner. There is a stapler in the K22 computer room.

Grades will be based on both correctness and code quality. Some assignments will also require you to discuss your results. Correctness measures whether it computes the proper answer or properly implements the assigned algorithm. This is a relatively objective measure. Code quality is more subjective, and includes a variety of factors such as efficiency, style, layout and readability, comments, output, using the appropriate constructs, etc. You will not be graded specifically on testing, but you should provide enough examples to convince me of the correctness (and illustrate efficiency, output, or other features).

Style, layout, and comments are topics that we will cover various times during the semester, so the standards will evolve. To start with, however, here are a few basics:

Style: Avoid global variables. Keep functions short. Name variables and functions mnemonically. We will discuss using a functional style, abstraction, and data hiding, but if you already know what this means, make use of it.
Layout: Since Lisp code tends to consist of nested function calls instead of sequential statements, the most important piece of information to convey visually is the nesting level, indicated by the level of indentation. Be sure entries at the same nesting level are indented the same, and entries nested at different levels are indented differently. I recommend letting emacs do your indentation for you automatically. Since the editor balances parens, and the indentation already indicates nesting level, putting each close paren on its own line tends to detract from readability.
For instance, compare the following:
Point: removing most of the parens and leaving correct indentation (column 2) is more readable than leaving the parens and having wrong indentation (column 3).
Comments: In general, comments (or doc strings) at the beginning of a function are sufficient. Document what the function does (abstractly), not how the Lisp code (concretely) implements that. For most functions, one or two lines is sufficient.

Regarding academic standards, students are free to look in any source or speak to anybody about any assignment. As in all courses, sources should be listed. You are free to adapt code out of texts, journals, Internet Lisp code repositories, or other public sources, as long as these references are listed. The same style and documentation standards will still apply, and you are responsible for convincing me that you understand how any borrowed code works. However, adapting code is not permissible with regards to other individuals, in contrast to standard sources. Copying of code from individuals, whether or not they are currently in 605.724, is not allowed, even if it is adapted and the source given. Not all situations fall neatly into either category: please contact me if you are unsure.

"Lisp is not the center of the world."
Richard P. Gabriel, "Lisp: Good News, Bad News, How to Win Big", AI Expert, June 1991.