CS 1705: Lab Assignments

Lab assignments are due during your lab period each week.

  No.    Topic(s)    Due  
  01   Collecting Beepers   08/28-29  
  02   Walking a Maze   09/04-05  
  03   Planting a Row of Beepers   09/11-12  
  04   How Many Beepers Are There?   09/18-19  
  05   Beeper Squares   09/25-26  
  06   Rot-13 Decryption   10/02-03  
  07   Counting Lines   10/09-10  
  08   Building a Gradebook   10/16-17  
  09   Spelling Checker   10/23-24  
  10   Time Table   10/30-31  
  11   Karel Interpreter   11/06-07  
  12   Debugging Bricks   11/13-14  
  13   Scriptable Calculator   11/20-21  
  14   Mine Sweeper   12/04-05  

Lab Grading

Lab assignments will be graded according to the following general criteria:

  • The solution adequately addresses the problem at hand.  Specifically:

    • The solution clearly represents a good-faith attempt to address the requirements for the assignment.

    • The program compiles and executes.

    • You have written enough tests to demonstrate that your code meets the requirements of the problem.

    • The program runs correctly, in that it passes all of your tests.

  • The solution constitutes a high quality product expected of a professional.  Specifically:

    • The program is easy to read and to understand, i.e., it is well commented and adheres to the course standards for layout and format.  For example, operation and object names are appropriate and thoughtfully chosen, and all potentially confusing/complex program code (including non-trivial if-statements, loops, procedure calls, etc.) is adequately documented.  See the example programs in the text and on-line for suggestions about how to comment your code. See the PaintBox example in the course notes for suggestions on how to format your programs for readability.

    • The general design of the program is clear and reasonable.  For example, the program makes good use of classes and operations; and the algorithms used are appropriate for the task, are clearly explained, and are implemented in a sensible, understandable way.

    • All classes, interfaces, and methods include an appropriate JavaDoc description. Classes must include @author and @version tags (use the date you wrote the code as the version value), together with a description of what the class represents and what it is for. Methods must include a description of their behavior, together with descriptions of each parameter (@param tags) and the return value, if any (@return tag). Again, see the PaintBox example in the course notes for typical content.

Each lab assignment will receive a score based on the following scale:

 Mark   Meaning 
10 the solution meets all criteria well
9 the solution is not quite what was required, but the mistake is superficial
8 the solution meets most criteria, but there is some room for improvement
6 the solution is just satisfactory; it meets some criteria but there is significant room for improvement
4 the solution is barely acceptable; there are serious shortcomings in meeting most criteria; it needs a lot of improvement
0 the solution is not acceptable

In cases where two separate tasks require a graded submission in lab (e.g., a lab with two parts), each part is graded on an equivalent 5-point scale.

Students often wonder why a seemingly small error can cause a relatively large grade deduction.  The reason is that software that does not work properly even in the smallest detail -- not in these assignments, of course, but in the "real world" -- can be costly or even dangerous to its users; and software that is difficult to change can be costly to companies that develop it.  Most employers of software professionals therefore have high standards for quality.  We want you to get used to this: to understand that "almost right" isn't good enough for most employers, and that as a professional it shouldn't be good enough for you even if it were good enough for your employer.  Therefore, an error that prevents your program from working (especially from compiling properly so it can run at all) can result in a significant grade deduction.  This means it is usually better to continue working on a program after it is due, taking a deduction for lateness, than to submit a buggy program.  Once you start getting 2-3 days late, however, it's probably a toss-up unless you're sure you are going to get it working soon!

 

copyright © 2009 Virginia Tech, ALL RIGHTS RESERVED
Last modified: January 22, 2009, 9:07:13 am EST, by Stephen Edwards <edwards@cs.vt.edu>