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 these steps 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! (Here's a freebie: don't optimize any piece of code until you've tested your program's speed and discovered that that code is a bottleneck.)

Turn-in procedures:

We're still debating about whether programming assignments will be turned electronically or in paper form. Stay tuned until we decide.

For each programming assignment, there will be an electronic turnin which is due by the stated time on due date or considered late (yes, one minute late is late; yes, we do get time stamps; no, they are not changed by touching the files). You may, however, submit programs one weekday late at a penalty of 20%.

Include all code files and header files required to compile and run your project in your submission. Also, include any other files (such as sample input) necessary for correctly running your program. Among these should be a makefile which will correctly compile and link your code when the command "make" is executed! Do not send executables, or sample output. Finally, you may include a README which describes your submission.

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

• your name, 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.