Robustness: Your primary task is to create a working, robust program. This means that your program should produce correct answers on all legal input and produce comprehensible error messages on invalid input. Keep in mind that (unless otherwise mentioned) unreasonably long running time is probably an error. How should you ensure robustness? Well, at the least, try to complete without problems all four Unpatented Wolfman Steps to Robust Code^!TM in succession on the Linux instructional UNIX machines (fiji, ceylon, sumatra, tahiti) before submitting your code:

• Compile without warnings or errors with g++'s -Wall flag enabled. (Notify us of errors in our code.)
• Run correctly on all test data we give you. (Tell us if you find our test data in error!)
• Run correctly on test data of your own which has:
  • difficult cases
  • boundary cases (both sides)
  • minorly and egregiously incorrect input
  • the empty file
• Run correctly on the test data of another group. You must credit this group in your README.

Coding clearly: You should always make an effort to write code that is easy for other people to read. In the real world, this is an important skill that is valued higher than cleverness or using the least number of lines/characters possible. In this class, it is important so that we can understand your program and grade it fairly. By reading through your code and comments, we should be able to figure out how your code is organized and why it works. If we can't, we reserve the right to deduct points.

Commenting: One aspect of writing clear code involves commenting your code so that it is clear what it does without reading it line by line (nothing is more boring). Comments should be used: (a) at the top of each file to tell what code it contains, (b) at the top of each function to tell what it does, (c) at the declaration point of important variables, (d) on any lines whose purpose is non-obvious.

Coding simply: Although C and C++ allow it, there is no benefit to writing overly complicated statements such as:

    if ((i = myfunc(counter++)) < num_iterations) {
       ...
    }

when they could easily be rewritten in a clearer manner:

    i = myfunc(counter);
    counter++;
    if (i < num_iterations) {
      ...
    }

Coding should not be a macho activity. It should be like writing English sentences that you truly want someone to understand (including yourself).

Speed: As long as your program takes a reasonable amount of time, we will neither dock points nor give bonus points on the basis of speed. In other words, all of your data structures should have the expected asymptotic time and space complexity, but the constants will not generally matter. Robustness and clarity come first! If you're curious about how to make programs run blazingly fast, talk to us, and we'll give you some tips and tools. (Here's a freebie: never optimize any piece of code until you've tested your program's speed and discovered that that code is a bottleneck.)

Working Individually vs. with Partners: All of the programming assignments this quarter will be designed to be completed in teams. If you choose to work on a programming assignment individually, you may collaborate during the brainstorming stage as described on the course syllabus (cite the individuals you work with in your README), and we will try to simplify the assignment slightly for individuals. However, we expect that all of these assignments will be easier completed in groups!

You are welcome to work with a partner for any or all of the programming assignments. Some assignments may be done in larger groups (as specified in the assignment writeups). Ideally, we view this as a way for two people with complementary skills to tackle the assignment together in order to deal with difficulties in the development process, bugs in their code, or problems with UNIX/g++. I've often found that two heads can often be better than one in these situations. Our expectation is that both people will work on the program together rather than dividing the program into two halves and trying to sew the parts together the day before the project is due, but you are allowed to do this (strongly discouraged but allowed). For those of you who decide to work with partners, here is what we expect of you:

• Announce to us via e-mail no less than three days in advance of the due date the composition of your team.

• Working with partners only applies to the programming assignments. Written assignments must be still be done according to the Collaboration section of the syllabus.

• Partners will turn in a single programming assignment that is the result of their combined efforts. Partners will receive the identical grade on the programming assignment except in extreme cases which are reported before the assignment due date.

• Partners will describe their division of labor in the README.

• Each partner may also turn in a short, private statement of what role they took in the programming assignment and what role their partner took.

• Both partners are expected to understand the entirety of the code, and questions pertaining to the assignments may be assigned on the homeworks or on the midterm/exam to ensure this.

• If you're working in a public lab, you must be sure not to disturb others around you as a result of working together.

We firmly believe that there is great value in programming in pairs -- it's amazing what two pairs of eyes can catch that one would've missed. The above rules are obviously set up to make sure that both people learn from the assignment and understand its point without one completely carrying the other. If you have any questions or problems with these policies, let us know or simply work by yourself.

Turn-in procedures:

For each programming assignment, there will be an electronic turnin which is due by 10PM on the due date or considered late (yes, 10:01PM is late; yes, we do get time stamps; no, they are not changed by touching the files). Only one person should turnin the code! People working as partners may also turn in their private statements of who did what, but we can only take action affecting the grade on the assignment if these statements are turned in before the due date.

You may however, submit programs after the due date by a total of four days over the course of the quarter. These are your late days. You may move one assignment by as much as four days or all four by one (or any other exciting combination!). Late days move the due date from 10PM one day to 10PM the next (or, as a special exception, from Friday 10PM until Monday 10PM regardless of holidays). Every member of a team uses one late day for each day the program is late. If any team member runs out of late days before the assignment is submitted, the entire project is late and will receive no credit. We may be flexible with due dates if you contact us in advance of the original due date (the more in advance, the more flexible we're likely to be). Please try also to tell us before the due date if you're using late days, but this is not required.

Generally, the contents of the README will be described on the assignment writeup, but here are items that should always be included:

• your name (or the team's and all members' if you're working in a team), UWID, and assignment number
• a brief (1 short paragraph) description of your assignment: what ADTs/algorithms you used, any bugs or features that are not working as well as they should (better to admit to them than have us discover them), any design decisions you made, or unique aspects of your code (especially anything above and beyond what was assigned)
• a brief description of the files in the submission which you created or changed. For example:
  main.cpp - our main C++ file for the program
  list.cpp - our list ADT implementation
  list.h - our list header file
  hash.cpp - Weiss' hash table implementation with our changes
  input/input1.txt - Sample input that shows our program works input/input2.txt - Malformed sample input that shows our program handles errors etc.