Monthly Archives: May 2012

Writing and asking the purpose of program code.

Example from a lab early in a Data Structures course:

//Lab Followup: Write a comment after EVERY LINE YOU WRITE OR CHANGE
//that demonstrates that you understand the purpose of that line
//in terms of the problem goal.  
//Bad example:  i = i + 1;  //Add 1 to i or Increment i
//Good: The count of dog bites is updated when we are bitten by a dog.


Here I’ll draft a collection of instructions or guidelines for CS TAs, useful for profs too.

  1. Provide enough information for students to account for every point of credit lost on assignments that did not receive 100% credit.
  2. Never dictate or tell students specific code for which the intention of the assignment is for the student to figure out that code him or herself.
  3. Set specific deadlines for when grading of an assignment must be completed.


  1. Set up and enforce a policy so that after a student gets help the student must code or continue coding his/her own solution without looking at certain material such as code or design sketches (in more advanced) that a helper showed to explain how to solve the problem.
    • Challenge aspects:  When a solution is worked out by a group, especially when it is based on or refactors code that is printed in the textbook, seems unreasonable to the student to refrain from electronically copying a solution file after it is finished by someone else.
  2. place holder…