CS/ECE 354 Machine Organization and Programming Fall 2008 Section 1 Instructor Mark D. Hill TAs Mark Liu & Somayeh Sardashti

CS/ECE 354 - Machine Organization and programming

Grading Guidelines for Programs

Keep this document with you when you are writing programs for this course. It clarifies 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.

15-30% 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 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?

 

5-10% Programming Style - 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?

10-20% Documentation - based on the internal documentation in your code

• program/procedure headers
  • the program header should include the following:
    • your name,
    • your section number,
    • the due date for the program,
    • the assignment number,
    • a description of what the program does ( one sentence)
  • procedure headers should include the following:
    • the name of the procedure,
    • a description of what the procedure does (one sentence),
    • a description of each input ( parameters from the calling program - does not mean keyboard input),
    • a description of each output (return values given back to the calling program - does not mean output to the visual display). Each input and output can probably be described with fewer than 5 words.
• variable/register descriptions
  • 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. Use the symbolic names for the registers, for example, $t0 rather than $8. (We will talk about registers in Chapter 8.)
• 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.