CS/ECE 354 - Machine Organization and Programming

Grading Guidelines for Programs

This document attempts to clarify what is expected from your programs.

The programming problems will be graded according to the guidelines below. The actual percentages may vary on particular assignments: the numbers below are to give you an idea of the relative importance for getting correct output, documentation, etc. Note that merely getting correct output does not itself guarantee a high score. For each programming problem, a sheet explaining the grading of your program will be returned to you.

30-50% Correctness - based on the test cases used by the graders

You will not be given the test cases in advance. This part of the program score will be based on how your program responds to typical inputs, unusual inputs (such as 0 when a nonnegative numerical value is required), and error cases (such as letters typed when numerical input is expected). Each assignment handout will specify what unusual inputs and error cases your program is expected to handle.

 

20-30% Program Requirements - as stated on the assignment handout

• Does the code contain/implement all listed requirements?
• Does the code suggest that the student learned that which was intended by the assignment?
• Does the code indicate that the student understands the purpose of the assignment?
• Has the student put into practice topics that should have been learned from previous programs?

 

10-40% Programming Style and Documentation - based on good programming practices

• Are variables names and labels descriptive?
• Is the program well organized?
• Did the programmer use simple, straightforward algorithms when writing the code, or were complex blocks of convoluted code used to perform simple tasks?
• program/procedure headers
  • the program header should include the following:
    • your name,
    • collaborators, when appropriate to the assignment
    • a description of what the program does ( one sentence)
  • procedure/function headers should include the following:
    • the name of the procedure,
    • a description of what the procedure does (one sentence),
    • a description of each parameter
    • a description of each return value
• variable/register descriptions (for assembly language programs)
  • Each variable declaration should be accompanied by a brief description of what that variable is used for.
  • Each register used in a program/procedure should be listed in a comment at the start of that program/procedure, along with a description of what its contents are used for. When doing the program that requires function implementation using register usage conventions, use the symbolic names for the registers
    $2 ($v0),
    $3 ($v1),
    $29 ($sp), and
    $31 ($ra).
• inline documentation
  • Include brief descriptions (sometimes a few words, other times a sentence) of functional chunks of code. A functional chunk could be one or two lines, or it could be 10 or more lines. When you write a few lines of code to accomplish something, include a comment indicating what it is that your code is accomplishing.