How I Grade a Programming Assignment

I read the program text and the trace file that demonstrates how it works. I assign a base grade according to the criteria below, and then adjust that grade up or down according to program style, as outlined below.

Feel free to use Python statements that we haven't discussed yet in class, if you like; but this won't earn you extra points.

Feel free to add features to your program beyond what was assigned: this could earn you extra points if you do it correctly and with good style, and if you don't neglect the assignment in your quest to impress.

• Is it on time? Programs turned in more than a day late (without a reasonable excuse) will receive lower grades.

• Is it original work? The Intellectual Responsibility policy is strictly interpreted in this course. Do not work together on programming assignments. Do not look at another person's code while you write your own program. Turning in something that represents your own work but is incomplete could earn you an F worth 50 points. Turning in work that is not your own could earn you an F worth 0 points, and a talk with the Dean.

• Does it compile? A program that is mostly written, but can't be run due to compile errors, would normally get about a D (65 points) as a base grade.

• Does it work correctly on correct inputs? A program that works correctly but has style problems would normally get around a B (85 points) near the beginning of the semester, and a C (75 points) near the end of the semester.

  Note: Every Computer Science professor I know will get in a snit if you turn in a program that you know doesn't compile or doesn't work correctly, but you don't bother to mention it (perhaps with a little scribbled note). The professor will think you're trying to pretend that it does work.

• Does the program show good style? A correct program written with good style gets an A (95 points). There are several aspects to good style. First, the program text should be easy for the human reader to understand:
  • There should be comments at the beginning naming the author and explaining what the program is supposed to do. Other comments should appear where appropriate to describe what sections of the code are supposed to do.

  • Variable names, and their types, should reflect their roles in the program. For example, year is better than a or howdy for a variable that represents a year.

  • Variables names start with lower case letters. Named constants are in ALL CAPS. Compound words (variables or function names) can be written with caps like this: totalCost or computeGrades, or with underscores between the parts. Be consistent.

  • Use blank lines to provide visual cues about the structure of the program.

  • My personal pet peeve is really long lines (printlines, long arithmetical expressions, etc) that wrap around and mess up the indenting. Break up an extra long line across several lines to improve readability.

  • The program should be broken into functions in a thoughtful way, according to discrete tasks. Functions names should be well chosen.

  The second aspect of good style is having a polite and easy-to-understand user interface. The program should be easy to use. It should give the user clear instructions about what to do and what kinds of inputs are valid. It should be not-too-terse and not-too-wordy.

  The third aspect of good style is robustness: how the program behaves when the user types in unexpected (wrong) inputs. A polite refusal to work with bad inputs is better than a program crash, which is better than a silent failure (producing wrong output with no indication that it is bogus). Robustness will become more important to your grade as the semester progresses.