Remarks on Grading of Programs

How is your grade on a homework assignment, consisting of a computer program, determined? I generally apportion the grading into the following categories, which are not given equal weight:

  • Logic: Does the program execute correctly? Does it satisfy project specifications? This is the component of the grade that has the most weight. For example, this will typically be graded for 50 to 55 possible points when the project has 80 possible points.

  • Listing: Is your code well-commented? Is your program explained? Do you identify yourself as the programmer? Is every subprogram and data structure explained? Do you use English properly (spelling, grammar, word choices)? Are your remarks correct? This is typically the 2nd most important component of the grade for C++ projects (typically 15 possible points when the project has 80 possible); in Visual Basic it will have somewhat less weight (e.g., 10 points possible when the project has 80 points possible) since the VB "pretty printer" automatically does a lot of formatting for you.

  • I/O (input/output): Is your i/o attractively arranged? "Attractively" refers to spacing and alignments as well as spelling and grammar. Are your prompt messages clear to an average user? This component of the grade might make up 5 possible points out of 80 possible for a C++ project; perhaps 10 to 15 possible points out of 80 possible points for a Visual Basic project.

  • Demonstration: Have you shown everything your program is capable of doing? This includes error messages when input errors are recognized; thus, a good demonstration may require you to use bad input data in order to show your program is capable of recognizing bad input. It also includes every type of possible response to good inputs. This is typically graded as 5 possible points on a project worth 80 possible points.
    NOTE: redundance is not called for -- 3 demonstrations of the same kind of program behavior is not 3 times as good as one such demonstration.
    In classes that use Visual Basic, due to the highly graphical nature of the class' activities, you are expected to give the instructor a demonstration of each of your programming projects. In classes that use text-based C++, it is sufficient to submit a document that illustrates all program behaviors.

The weights given to these components will depend on the size of the project, the programming language in which it is written (for example, the arrangement of i/o may be given more weight in a graphically-oriented language like Visual Basic than in text-based C++), and the material it is designed to cover. Thus, the following remarks illustrate typical examples but should not be taken as hard-and-fast rules. Note also that your score in each category will be non-negative. Note also my Web pages On Programming Style (C++ version; Visual Basic version) which contains many relevant examples.


Logic

For a project on which the total possible points is between 40 and 100, typical penalties under this category include:

  • Neglect of, or total failure to satisfy, a project specification. For example, you might be required to have your program sort data, but fail to do so. Depending on the seriousness of the requirement, this might cause a loss of 5 to 15 points.

  • An error in logic attempted. For example, you might have an incorrect formula for an arithmetic calculation, or you might have mixed up the maximum and minimum operations, or you might have incorrect values governing the repetition structure of a loop. Depending on the seriousness of the requirement, this might cause a loss of 3 to 10 points.

  • Poor modularization: 2 to 5 points.

  • Unnecessary global variables: 2 to 5 points

  • Unnecessary side effects: 2 to 5 points

  • Poor choice of programming tool (e.g., using a do loop when for is more appropriate; using a series of if statements when a C++ switch or a Visual Basic Select Case is more appropriate): 1 to 3 points


Listing

For a project on which the total possible points is between 40 and 100, typical penalties under this category include:

  • Inadequate documentation may cost you 3 to 10 points, depending on how badly you have explained your code and how much weight is given to this category.

  • Inadequate spacing in your code (for example,
    cout<<score;
    rather than
    cout << score;
    notice that the 2nd version is easier on the eyes than the first) may cost you 1 to 2 points, depending on how often it occurs in your code.

  • Indentation/alignment that does not illustrate the block structure of your code: similarly, 1 to 2 points.

  • Use of "magic numbers" instead of named constants: 1 to 2 points.

  • Spelling, grammar, word choices, and other abuses of English: These penalties, I assess by an estimate of their density. That's because I don't want to penalize length. You might lose 1 to 5 points, depending on the frequency (not the count) of such errors in your code.

Excerpts from the "Kode Vicious" column by George Neville-Neil, Communications of the ACM 53 (12), 2010, pp. 37-38:

Dear KV,

Do spelling and punctuation really matter in code? ... one of my professors ... takes points off of our programs if we spell things incorrectly or make grammar mistakes in our comments. This is completely unfair. Programmers aren't English majors and we shouldn't be expected to write like them.

Miss Spelled

Dear Miss Spelled,

Who is your professor and can I please send him or her some flowers? ... The amount of code I have had to beat my head against because the original author did not make his or her intent clear in the comments, when there were comments, is legion, and all that head beating has given me many headaches. It cheers me to know someone else out there is beating your head for me, so maybe, someday, my headaches will go away....

Clear code is actually more aligned with clear writing than most people are willing to admit. Many programmers seem to have gone into their field to avoid ... English or anything that would require communicating with other people rather than machines. That is unfortunate, because code is a form of human communication.... Code is not just for computers; it is for other people as well. If the next person who reads your code - in your case your professor, but after school it will be your workmates - cannot make heads or tails of it because you failed to write in a clear manner, then that is sloppy work on your part and deserves poor marks.... Remember, whether you like them or not, other people are going to read your code, and you owe it to them to make what you wrote easy to read.
KV


I/O

Most flaws under this category will be penalized one point apiece, at most. These include errors in spelling, grammar, and other abuses of English; poor alignments/spacing; unclear, awkward, or misleading prompt messages; etc.

In Visual Basic, additional factors may include color choices and contrasts, font properties, etc. Regarding these, I will not demand that you make the same choices I would make, but I will expect your choices to result in i/o that is pleasantly arranged and easy to read.

Note if your program does not run, you may be unable to give an adequate demonstration of your i/o, hence will receive a low score (possibly 0) for this component of your grade.

Demonstration

Most flaws under this category will be penalized one point apiece, at most. However, if you submit a program that does not run, you cannot demonstrate its run-time behavior, hence should expect to receive a score of 0 for this component of your grade.