Programming assignments are different from lab assignments in that they are larger and more elaborate. Typically you will have two to three weeks to do one and turn it in. The Documentation Standard will not be adhered to strictly in lab assignments; it will be in programming assignments. Lab assignments are meant to give you practice writing small pieces of code. Programming assignments allow you to develop larger programs that require more thought and time.
Program Test Plans: A test plan is a set of test cases that are used to test your program. Each case has a description of what it is testing, inputs that cause that case to happen, and the expected output/outcome of that input.
They are designed to make sure that all parts of your program are executed and tested in different situations. When your implementation is done, make sure you run the test cases in the test plan! That is what it is for. If you find an incorrect output or an error that crashes your program, you need to fix it.
Complete test cases will be given for some assignments. These will also be used to grade the assignment (not all of the points but a substantial number). So you are well advised to run your program with these test cases to make sure that it works correctly.
Program Designs: A design or an algorithm is a rough draft or outline of a program. It is important to do a design before you actually write the program. You will be expected to write a design (in pseudocode) for all programming assignments. Your design grade will be part of the programming assignment grade. There are several examples of designs on the class web page.
Assignments will have a list of things the student MAY use, that the student MUST use and a list they MAY NOT use. Following these instructions are part of the grade. All students are encouraged to use what has been done in class - in lectures and in labs. See "if you are tempted to use something not done in class" on the Program assignments page for a discussion of why this is.
Documentation is important to any program. With good documentation, you can go back six months later, pick up the program and understand what you did and why you did it! Comments should NOT just repeat code; they should explain WHY the code is the way it is. Documentation is a way to communicate to the person who is grading your program while they are grading it! A programming standard which you are expected to follow will be described and developed during the course. It is posted on the class web page. Programs can lose points for poor documentation or style, even if the program works! This standard specifically states that you must include your name, section and email address, the date turned in and the purpose of the program in the header of the program. This is very important if we need to contact you quickly about your program. The header is the first place we will look for your preferred mail address. If nothing is there, the only other address we have is the University one (uky.edu). If you don't get a message in time because it went to an address you don't read, that is your problem. You will be penalized for late submission.