Programming assignments can be long and complicated, contain many steps, and require a lot of coding. We do our best to make sure that they can be completed in the time available, and with a minimal chance of losing marks for unexpected reasons. Still, potential issues can and do arise. Here are some additional notes that may help you avoid losing marks, and improve the state of our assignments in general.

Follow submission instructions

You can lose marks for things that are not explicitly stated in the assignment tasks. Failure to put specified files in their correct locations is an example. Generally, make sure to read assignment completion and submission instructions in full, and to prepare a submission that is clear, clean, and considerate towards the TAs.

Ambiguity and omissions in assignment specifications

No assignment specification is able to describe every step in perfect detail and eliminate any possibility of ambiguity. Some aspects of assignments are also intentionally left to your discretion. Wherever you think something is ambiguous or omitted, you are to use your own judgment. The essential thing to do is to identify and describe what you are doing and why. Document your decisions and especially any added features you implement if you want them to be recognized.

We always enjoy it when students take assignments in a new direction, adding features or new ideas. But in general, you should avoid changing the default behavior of the assignment. The TAs will expect to mark hundreds of assignments quickly, trying out the same sequences of operations to check completeness. If you add features to assignments that might change the default behavior, then make them optional whenever possible and document the changes.

If you think some aspect of an assignment specification or provided source code is broken or brain-damaged, it may well be! Let us know well before the assignment is due and we may be able to fix it or modify the specification and benefit everyone in the class. If you let us know after or very close to the deadline, we may not be take any action and we will handle how issues should affect anything at our discretion.

Credit for non-functioning code

It is possible for non-functioning code to be given a partial credit. It, however, must be requested in your hand-in and TAs will not grant code credit automatically.

What you are actually doing when requesting code credit is stating which objectives do not work properly and asking for the TAs to examine code to give you up partial credit for each non-functioning objective. For each missed objective, your request must state the following explicitly:

1. What code files do not work, and the relevant line numbers.
2. What execution features of the code in these files do not work (i.e., describe the current behaviour).
3. What you think the probable cause of the problem is.
4. What steps you have undertaken and will/would continue to undertake to track the problem down and correct it.

If you fail to provide this information, the TAs may not give you any credit for your code.

The code in question must be well organised, well commented, and clearly documented. You must make it easy for the TA to understand what you are trying to do in your code. If the TA cannot understand your code, you cannot expect them to give you any credit for it.

Academic integrity

Our programming assignments are designed to give practice on the topics presented in lectures. It is important that you do all by yourself to maximize your learning experience. One activity that promotes learning is discussing the assignments, in class, with the instructor, with the TAs, and with others in the class. These discussions are to be preliminary in nature, exploring the possible tools, techniques, and issues involved in the solution.

The second activity that promotes learning is that each student individually works out a solution and composes their own code to execute the assignment. If you take this course, you agree to be bound by this requirement, along with all the rules for academic integrity. If you are found out not following these rules, we will always apply the full expected penalty, which is severe. Be mindful that discussions after you have worked out your solution might pose you and others to a risk of cheating. If you ever have any questions about what may or may not constitute cheating, please ask the instructor first so you don't end up breaking any rules by accident. Please do not post solutions to assignments in a public place online or anywhere else that future students might gain access to them.

Use of outside assets and your own past code

The rule number one is that the code you submit should be code you wrote. In some cases, it may make sense for you to use assets (e.g., 3D models) provided by someone else to assist you in your work. Further, you may wish to reuse code you wrote in other courses. In both cases, you should check with the instructor beforehand, and credit the code (even if it was code you wrote for other courses or work) in your documentation for the assignment/project. If you do so without our permission, you will a certain penalty. However, you do not need to give credit for code that we provide for you.