Programmming Projects

Pair Programming

In the opening comment section of your program be sure and include a "pair programming log" following this template:

/*
  This program was completed using pair programming by me
  (PUT YOUR NAME HERE) and my partner (PUT YOUR PARTNER'S NAME HERE).
  I acknowledge that each partner in a programming pair should "drive"
  roughly 50% of the time the pair is working together, and at most 25%
  of an individual's effort for an assignment should be spent working
  alone. Any work done by a solitary programmer must be reviewed by the
  partner. The object is to work together, learning from each other, not
  to divide the work into two pieces with each partner working on a
  different piece.
  I spent ______ HOURS working alone.
  I spent ______ HOURS working with my partner on this assignment.
  I estimate that of the time spent with my partner, I "drove" _____
  PERCENT of the time. 

  Put any comment or explanation about variations from the 
  expected pair programming practice here. E.g. if you didn't complete
  the assignment with your partner, this is the place to explain why
  not. 
*/

/**
 * Assignment #1.
 * This program generates anagrams...
 * 
 * Authors: Charlie McDowell (mcdowell@ucsc.edu) 
 *          and Jane Programmer (jprogrammer@ucsc.edu)
 */

You should also read the pair progamming guidelines and policy for the class. This explains what is considered to be acceptable pair programming and what to do if you have problems with your partner.

Programming Assignments

• Programming project 1: Due October 11th at 11pm (preliminary due October 8th at 11pm - NEW DATE)
• Programming project 2: Due October 25th at 11pm (preliminary due October 18th at 11pm)
• Programming project 3: Due November 8th at 11pm (preliminary due November 1st at 11pm)
• Programming project 4: Due November 27th at 11pm (preliminary due November 17th at 11pm)
• Programming project 5: Due December 8th at 11pm (preliminary due November 31st at 11pm)

Grading of Individual Projects

Late policy: 1 minute to 1 week late is minus 10 points. After 1 week it will not be accepted.

Be advised that WebCT can sometimes get rather slow near a deadline, when many students are trying to submit. If you have a working program and are just "touching up the style" or doing some final testing, go ahead and submit it. You can always resubmit up to the deadline without any penalty, but if it gets too busy and you fail to submit in the last 5 minutes before a deadline, then you missed the deadline (like getting stuck in traffic - plan ahead and leave enough time).

Grading Breakdown

• 5 points: Fail to include a proper pair programming log in the opening block comment.
• up to 50 points: Woefully incomplete implementation. This is intended to prevent students from getting 50 points for a stylistically correct nearly vacuous file. It will not apply to any program that made a serious attempt to implement all required features.
• 100 points: Including code from any source other than the identified (at the top of the file) creator(s) without proper attribution.

Style (maximum deduction 50 points total, 10 points for any one category): Note that some of the following refer to language constructs you will be learning about during this course. If a style requirement mentions a language construct that you don't know about (e.g. "break") feel free to ignore it until it comes up in class. You will be responsible for following all that refer to topics covered prior to the due date of a particular assignment. If you aren't sure if an item will apply to a particular assignment, it will never hurt to ask. In general the items are listed in the order you can expect to have them apply.

• 1 point: Each occurance (up to 5 maximum) of lines that are more than 80 characters long (including spaces). If you connect with ssh most likely the default width of your terminal window will be 80 characters. Make sure your program looks ok there when displayed with "more".
• 2 points: Each method not preceeded by a meaningful block comment.
• 5 points: Each source file not beginning with an informative block comment including the name(s) of the creator(s).
• 2 points: Each non-descriptive identifier (class, method, constant, or variable).
• 1-10 points: Inconsistent or inappropriate indentation or the presence of TAB characters in the source file. (Convert all tabs to white space and check indentation before submitting. You can use the Unix command expand.) NOTE: This does not mean that you should not use tabs when creating and editing your source code. It does mean that you should use the expand command to replace the tabs with spaces before submitting your final program or use an editor that automatically converts tabs to spaces.
• 2 points: Each "magic number." A magic number is a literal constant (with the exception 0, +1, and -1) appearing anywhere in the source of a program except to initialize a symbolic constant (e.g. "static final int size = 5;" is ok, "for (i = 0; i < 5; i++) ..." is not (because of the 5 not because of the 0). If a numeric literal occurs only once, then creating a constant is not mandatory but still often helps with documentation.
• 2 points: Each use of a series of if-statements (without else clauses) when an if-else is called for.
• 2 points: Each use of "break" in a loop when the loop predicate could easily be modified to handle the loop temination without a break.
• 5 points: Using an integer where a boolean is called for. E.g. don't use "while (hasMoreInput == 1)...", use "while (hasMoreInput) ...".
• 5 points: Each unnecessarily long method (over 50 lines is definitely long, under 25 is almost certainly safe).
• 5 points: Each global variable other than a static final... used to create a symbolic constant.
• 5 points: Each occurance of a repetitive sequence of lines that could/should be easily converted into a method.