CMPT 318: Expectations for Assignments in General

CMTP 318: Assignment Expectations

Last updated: January 13, 1999

N.B. Not all of this file may apply for each assignment. When in doubt, ask your TA during office hours.

Presentation

Your assignment should have a cover page which clearly lists the following:

Course name and number
Assignment name/number
Your name
Your student number
Date submitted

Source code should be printed in a monospaced font, such as Courier. If you're using something like 'mpage', which puts several pages of output on one piece of paper, make sure the output is still legible.

The entire assignment should be stapled, not held together by paper clips, string, etc. (Enclosed within a duo-tang is acceptable, but no binders please; they're too bulky.) To save paper, you may submit double-sided printouts.

Your javadoc-compatible comments are required in the source code, but you do not have to hand in printouts of the javadoc-generated HTML.

Many assignments have you change existing code. You should not hand in code that you have been asked not to change. When printing your code please make sure you're printing the entire class that has changes made to it. Don't hand in just the lines that were changed. Obviously you have to hand in all new classes that you wrote.

Coding Style

In general you should try to adhere to a common coding style for Java. Your textbook contains a decent style in Appendix C. Note that his link at the end to additional style guides is stale, the new link is here. No matter what coding style you use, ask yourself the following questions:

Is your program easy to use? (From a user and/or programmer perspective)
Is your program easy to read?
Have you made good use of whitespace?
Does it have meaningful, succinct comments?
Do you make good use of constant and enumerated types?
Do you have meaningful variable/constant/function names?
Is your program (relatively) efficient? (eg. don't write O(n*n*n) code if O(n*n) is just as simple.)

Documentation

Please be concise when writing your documentation. Strive for clarity. You must include javadoc documentation for method headers. You should also include inline documentation for tricky code. If it is needed, inline documentation should describe what you did and why. Simply explaining line-by-line what your methods do is not very useful to anyone.

As mentioned above, you do not need to hand in copies of the HTML generated by javadoc. The point of the javadoc comments is to ensure the standard comment style is being used.