Assignment Handouts
Assignments will be posted here when they become available. For instructions on submitting assignments electronically, see this link.
Assignment remark requests should be made with the proper form available in the forms section of the website.
| Assignment | Weight | Solution |
|---|---|---|
| A1 Handout | 5% | A1 Solutions |
| A2 Handout | 10% | A2 Test Cases |
| A3 Handout | 10% | A3 Solutions |
| A4 Handout | 10% | A4 Solutions |
Assignment Expectations
Your assignments will be graded on the following criteria:
- Correctness. This means that your solution behaves according to the specification outlined in the assignment statement. Usually we'll be testing for correctness by running our own set of unit tests. As such, please be sure to follow the assignment statement to the last detail, and in particular, always obey the instructions with regards to what you should be returning from functions/methods, and what kinds of arguments functions/methods expect. If you do not, then you will potentially lose a lot of marks because the test cases will fail.
- Design. Your code should be well structured. You shouldn't have overly large methods and functions -- they should be broken down into smaller, manageable pieces. Likewise, if you're working with classes, don't try lumping everything into one class when it makes more sense to split functionality across multiple classes. Also, ensure that the classes that you've defined are appropriate given the problem you're trying to solve.
- Style. This was discussed in the first lecture. Although we're not going to be overly pedantic and deduct marks for every small detail that violates a rule from PEP8/PEP257, we do want you to follow some rudimentary style rules. See the lecture notes from lecture 1 for more information on this. Also, consistency is important. If you do deviate from style rules, do so consistently throughout your code.
- Variable naming. You should give your variables meaningful names. Don't use random names like "xx1, xx2". For example, if something is a counter, then name it "counter". An exception to this is naming loop variables: nondescript names like "i" and "j" are typically used when iterating through a range of values in a loop, so it is unnecessary to provide more detailed names in this context.
- Commenting. Always always always comment your code. This includes writing docstrings where appropriate, and using block comments to enhance the understanding of your code. Don't go overboard, though. We don't want you stating the obvious. Comments like "This assigns the value 5 to x" for the code "x = 5" will result in marks being deducted.
- Testing. Unless otherwise stated in the assignment, you need to test your code. This is done using the nose unit test framework. We expect that you will write a sufficient number of unit tests to prove to us (and yourself) that your program is correct. When trying to determine what tests you should write, think about boundary cases and unusual inputs that your program may have problems with. Also think about "typical" cases.
- Other. Sometimes assignments may include non-programming tasks, such as answering questions.
Also keep in mind that even though this is a computer science course, we would like to see proper spelling and grammar in your submissions. This isn't something you'll be graded on, but please proof read what you submit.