This page outlines our expectations for your assignments. The grading scheme follows these points closely.
Homework assignments will be done in pairs. Students will work in the same pairs throughout the entire term. You may form your own pairs at the start of the term. The course staff will pair up students who do not express preferences.
Each pair should submit one assignment with both names on it. Both members of the pair will receive the same grade on the assignment.
Ideally, you and your partner should either try the problems individually and meet to go over results (and choose which answers to submit), or meet and work the problems together. We strongly discourage you from splitting up the problems and each working only half of them. Each problem is designed to practice a different sort of program. If you only do half of the programs, you may find yourself unprepared for the exams! (You must have a passing average on the exams to pass the course.)
Put another way, we use homework pairs because experience shows that most students do better in the course when they work regularly with someone else. We don't use them because the assignments are too long for one person to do. You are expected to work roughly 12-17 hours a week on the course outside of class. If you can't finish the assignments in that time on your own, you need to be coming to office hours for extra help.
You may use whatever you need (including things usually forbidden on homeworks), but any uses of set! must adhere to the guidelines for when to use set! (see bottom of the linked page).
Every program should be documented with
A contract, which is a comment documenting the type of the inputs and outputs of the program.
A purpose statement, which is a comment describing what the program computes.
A list of the test cases on which you ran the program.
Write your test cases as a series of check-expect statements that
call your program. You do
not need to include the results of the tests in what you submit.
The graders will be checking the quality of your test cases (do you
have too few, too many, sufficient variety, etc).
See the documentation example for a sample contract, purpose, and test cases. Many other examples will be given in class.
Whenever your program consumes or produces a compound form of data (structures, lists, etc) you must write down a data definition and examples of the data. A data definition is a comment describing the structure of the data and the types of its pieces. The examples of data are Scheme expressions that build instances of the data type you have defined.
See the data definition example. Many other examples will be given in class.
You should use appropriate types for your data. For example, if the problem statement suggests boolean data, you should use booleans rather than 0 and 1.
Your programs should follow the templates for the types of data on which they operate (this point will become clearer in the second week of class when we discuss data templates).
See the templates example. Many other examples will be given in class.
You should use helper functions appropriately. In general, use helper functions to
Your code should be readable, with proper indentation and line breaks (lines that don't wrap around). DrScheme will do proper indentation for you automatically (but not line breaks).
Unless otherwise noted, do not add error-handling to your code. Assume that your programs are run on data that conforms to their contracts. (Obviously, real-world programs do need to include error handling, but this course will not discuss MzScheme's exception mechanism, which is the proper way to handle errors.)
Your graded assignments will be marked with the identity of the grader who graded them. Talk to the grader first. If you still have a concern over your grade, talk to the professor.