Here are some of the specific deficiencies that graders may be looking
for.  IMPORTANT: this is not a complete list.

================

Data Design:

-- bad design choices (eg: doesn't use mixed/recursive data where
   appropriate, bad/misleading field names)

-- missing/incomplete interpretation.  (Criterion: does the
   interpretation give you sufficient information to read and
   understand the submission?  Does the interpretation account for every
   value assigned to this field by the program? eg: setting a mouse
   position to zero)

-- missing/incomplete/wrong invariants. (Criterion: are there combinations
   of data values that are unaccounted for, regardless of whether they
   come up in execution?)

-- missing/incorrect templates.  When evaluating, try to distinguish
   between harmless errors and those that will hinder the programmer
   in correctly using the template.

================

Contract/Purpose Statement/Design Strategy:

-- missing/incorrect contracts.

-- missing/incomplete/misleading purpose statements. Purpose must be
   clear, correct, and add at least some information beyond the
   contract.  Ideally, the reader should be able to figure out what
   the function returns by reading the purpose statement and the
   examples, WITHOUT LOOKING AT THE FUNCTION DEFINITION.

-- purpose statement does not mention one of the arguments.

-- missing/incomplete invariant:  The function should fulfill its
   purpose for EVERY combination of inputs that is permissible
   according to the contract.  If not, the permissible combinations of
   inputs must be documented by an invariant (WHERE clause).  The
   WHERE clause may also be used to document assumptions about the
   arguments, e.g. "WHERE: the ball would hit the wall on the next tick"

-- missing/wrong design strategy.  Is the design strategy a reasonable
   description of how the function works?

-- function definition not "obviously correct".  Ideally, you should
   be able to tell whether a function fulfills its purpose just by
   reading the function definition and the purpose statements of the
   functions it calls (NOT the code of its helpers).

-- poor choice of function/constant names.  Names should be nouns
   whenever possible. The name should give a good indication of what
   the function does or what the constant denotes.  It should NOT
   mislead the reader.

-- poor choice of argument names.  Arguments should refer to the
   information, not to the data type. eg: 'ships' not 'los' or 'loship'.

-- Spaghetti code.  Code that is hard to understand because it has
   long call chains or many functions with similar names and purpose
   statements.

-- Student does not use appropriate programming techniques
   (e.g. doesn't use map/filter, doesn't eliminate annoying code
   duplication)

-- missing/incomplete/incorrect termination argument (starting week 08)

-- uses concepts/terms from previous semesters (Note: this may be the
   result of cutting & pasting from the example files, or it may be the
   result of the student using a solution submitted by a student in a
   previous semester.  If the student insists that it is the former,
   ask him/her to email you later showing you the source.)

================

Examples and Tests:

-- should have 100% test coverage except for functions that call big-bang.

================

Interfaces, Objects, and Classes

-- Interface has no purpose statement
-- Method in interface has no contract
-- Contract for method talks about classes, not interfaces
-- Method in interface has no purpose statement/inadequate purpose
   statement 

-- Class has no purpose statement
-- Class has no constructor template
-- field interpretation missing or inadequate
-- field interpretations/invariants inadequate to explain all values
   assigned by program.
-- public method not in interface (for-test:* methods are OK)

-- method has no contract
-- method has contract different from the contract in the interface
-- method has inadequate purpose statement
-- method missing examples if you think they are necessary to explain
   purpose statement
-- method missing design strategy if you think it is necessry to
   explain the code.

================

Presentation:

-- student shows lack of understanding of his/her submission

-- student has difficulty understanding questions that are asked

-- student has difficulty answering questions

-- student talks around answer rather than answering precisely

-- student's English is hard to understand (pronounciation)

-- student speaks too softly to be heard