Every assignment is different, so the detailed criteria for every assignment are different. In general, though, we grade on two things: Correct functionality and style.
The biggest cause for losing points is failing to read the assignment carefully, or not taking it seriously. The assignment says what the program should do, and if it does something different, you'll lose points. It's that simple.
Sometimes you see movies that are "based on the title of a real book." Sometimes I see programs that are "inspired by the title of a real assignment." Programs like that don't get high grades. Most of the points we take off are of the form, "[We said to do X, and] you didn't do X."
Now having said that, let me add that I'm delighted when you do what the assignment says, and more. There's a big difference between doing "something like" what the assignment asks for, and meeting the requirements and then adding extra features.
I can't always think of every possibility when I write an assignment. If I fail to specify something that seems important, bring it to my attention. If I don't tell you exactly what functions to write and what messages to print out, then it's up to you to do something reasonable.
You wouldn't deliberately turn in a program with syntax errors. But here are a couple of things you might do:
If your program crashes when we use it, chances are you didn't test it carefully enough.
Another possibility is that your program is "fragile"--you have to do exactly the right things, in the right order, to make it work. If your program has a
main function, it probably takes care of that. If the user has to call function X before calling function Y, or the program crashes, then you have a problem that needs to be fixed.
Since thorough testing is required in most assignments, you will lose points for inadequate testing, even if your program works. So test thoroughly. Remember, the purpose of testing is not to "prove that the program works," but to show where it doesn't. Find all the errors you possibly can, and fix them. If you miss some, chances are we'll find them and grade the program accordingly.
Unit tests should test each method by itself as much as is reasonable. This helps expose fragile methods that depend too much on other methods to set things up for them.
When unit tests are run, the program should never produce output or ask the user for input. If they do, this makes the tests a nuisance to use, so you won't run them as often as you should. It also means you have a poor separation between computation and I/O; in this, and in many other ways, TDD (Test Driven Development/Design) encourages better programming style.
Good style is what makes a program readable. That's key. If it's readable, then its understandable, modifiable, testable, and debuggable. Style is important!
I talk a lot about style as the semester progresses. You aren't expected to follow the style rules I haven't told you about yet, so the requirements get more stringent as the semester progresses. I have written a short list of the Style Rules for you to start with. In addition, you should read the official style guide, PEP 8 -- Style Guide for Python Code ,written by Guido van Rossum himself, at least two or three times during the Python part of the semester.
The convention for this class is to use underscores for naming multiword variables and functions. For example:
"Zipping" files is a way to compress them (make them smaller). More important for this class, it is also a way to combine multiple files into a single file that can be easily uploaded and downloaded.
For some assignments, your program will consist of only a single file. It is easier for everybody if you don't zip it first. But if your program consists of multiple files, Zip up the entire directory for that program, and submit the zipped file.
Important: "Zip" means the universally understood .zip format. Submissions using a proprietary format such as Microsoft's .rar will be penalized according to how much trouble they cause us.
All assignments are to be submitted via Blackboard.
You and your partner should decide who is to turn in the program, and you should submit one program for the two of you. Both of you will receive the same grade on the program.
You are expected to work as closely as you can with your partner. If you are unhappy with your partner, you are expected to behave in a professional manner and do your best under the circumstances; remember, you will get a different partner for each assignment. You will have the opportunity to provide an anonymous evaluation of your partner. Under extreme circumstances, and with the prior agreement of the instructor, you may do the assignment alone and turn it in for yourself alone.
Partners are assigned at the beginning of the Friday lab period. If you are unable to make it to lab, or if you are so late that your partner is reassigned to someone else, you will receive an automatic 10-point penalty for the assignment, and you may or may not get a partner. You can avoid the 10-point penalty if you email the instructor by Thursday that you will be late to or absent from lab.
It may happen that you don't get a partner for some assignment. For example, there may be an odd number of students in lab. If this happens, (1) you are expected to do the entire assignment by yourself, and (2) we will do our very best to make sure this doesn't happen to you a second time.
If you strongly dislike working with others, it might be wise to reconsider your choice of careers.
Unless specified otherwise, assignments made on Friday will be due the following Friday at 6am precisely. There will be a 10 point penalty (out of 100 points) for programs between one minute and one week late, and a 25 point penalty for programs later than one week. At some unspecified time after one week we will stop accepting assignments.