CS 4536/CS 536 Homework Style Guidelines and Expectations
Coding Style
We are very serious about requiring you to write clean,
well-documented code. 20% of your grade for programming
assignments will depend on your design, style, and comments.
Not already knowing Scheme or having learned Scheme with a different
style are not excuses for not following these requirements. We are
using the coding style
from How To Design Programs for this course (this is the same
style used in the text and in class).
- All functions must have a purpose statement that
fully explains, in a sentence or two, what the function does.
- All functions must have contracts (the comment summarizing the types).
- If you need to use a new type, define a new datatype to represent
it. Do not overload lists. Understand the difference between
lists and datatypes. Lists are homogenous collections of
unlimited extent. In contrast, datatypes are heterogenous collections
with a fixed number of members.
- As a general rule, all functions should be no longer than
what fits on a screen. We will of course relax this for
functions with a lot of pattern matching (
parse comes to
mind) and in that case recommend that each match case fits on a
screen.
- Assume that your reader understands Scheme, so, in any inline
comments, explain why you wrote the code, don’t explain
what you wrote. We consider
define-type to be
self-documenting.
Test Cases
All functions must have tests that exercise non-trivial cases. We
require this to encourage good software development skills, but, more
importantly, to force you to show us that you know what your code is
supposed to do and that you’re not getting a correct answer by
guessing. Testing counts for 20% of your grade on all
assignments unless stated otherwise. We will not give full
credit to untested functionality, even if it is correct!
Good test cases:
- Test a single aspect of a single feature. Therefore, you will need
multiple test cases per feature to ensure its correctness.
- Actually test the program. Testing means not only
executing the program but also checking the output to ensure it is
what you expected.
- Have a comment to explain their purpose.
When writing test cases, resist the temptation to make them massive
and complicated (the notion that “this must be testing
something”). Instead, write small, clean tests with
clear purposes. While a mega-test can be good for exposing errors you
didn’t think to write focused tests for, make sure that, should
your mega-test fail, you figure out what aspect of it triggered an
error and write a smaller test for that.
Back to the Assignments page