Assignments are to be done individually unless stated otherwise. Discussing the assignments with others is allowed, even encouraged, but work handed in must be your own. Often times, students wonder how much discussion is proper. A good rule of thumb states when discussing assignments with others, leave your pencil and paper at home.
Read the available information about academic integrity very carefully. Plagiarism detection software is used to screen assignments in this course to verify that use of all material and sources in assignments is documented.
Small is beautiful. Contrary to the belief of some students, the grade you receive is often inversely proportional to the size of your submission. The clearer and more standardized your submission is, the faster the marker is able to mark and return it. More importantly, a small, well formatted, clean submission almost invariably puts the marker in a better mood and increase the chance of a better mark.
Unless specified otherwise, Program and Testing documentation are always required.
Testing documentation is also handed in electronically via the submit command.
Program Documentation is the documentation that appears in the source code to aid in understanding the program. It is required for every program you write.
Testing Documentation is documentation to convince the marker that the program has been thoroughly tested. Each program must be tested and testing documentation must be provided. When you hand in an assignment, you must explain what test data you chose, and why you chose it, and what it shows about the correctness of the program. Then, you must test your program with this data, and explain the results. Your testing should be presented in such a way that the reader is convinced of your program's correctness. It is insufficient to simply show the results of executing your program on some arbitrary set of test data.
If necessary, divide the testing into sections. For example, test the user interface, then the correctness of the algorithm, then the program's error handling ability.
The following is the minimum required for testing documentation:
Explain what is being tested and list what files are used in the test. For example, explain what parts of the program and/or algorithm are tested by different sets of data values in the test file.
Use line numbers if possible when explaining test data, for example, "the test data on line 3 exercises routine Insert() of the program by ...".
Line numbers are essential when there are empty lines in the test data.
Line numbers can be generated using the -n option on the cat command and the output can be inserted into your testing documentation.
Program testing must be done in two steps. First, choose a set of test data to exercise all execution paths. Note, this does not imply tailoring testing to fit your particular implementation; it involves identifying the data that forms the set of critical case data. You are also required to test your program as a solution to a class of situations. For example, if you are writing a sorting algorithm, you should also test how it handles trivial cases, ascending data, descending data, random data, large sets of data, etc. As a general rule of thumb, take the perspective of a user who does not know about the implementation for a solution, but wants to ensure that the code meets all of the requirements. Second, you must execute your program with this test data.
The following outlines the minimal submission standards that an assignment must meet. An assignment is NOT marked until it meets the following specifications.
Most of the assignments you submit in this course contain programs. These programs are compiled and executed by the markers as part of the marking process. The compilation and execution procedure is automated, which means you must not prompt for further input if the received input does not meet your program's input criteria. It requires that you follow some simple naming conventions, and possibly, create some simple shell-script files or makefiles when submitting an assignment. These naming conventions are spelled out clearly in each assignment.
The submit command copies a program to a course account, and when the program is run under the course account, it does not have permission to read files back in your account.
Therefore, all includes in a submitted program must specify a relative file name, e.g.:
#include "include.h"
rather than an absolute file name, e.g.:
#include "/u/name/cs343/a1/include.h"
Use the web test compilation form to ensure that your makefile has been set up correctly, all the required code has been submitted, and an executable of the correct name is created.