Programming Assignment Guidelines

This file is copied almost verbatim from the Winter 2000 CSE 326 Programming Assignment Guidelines. It is used here with permission of the author, Steve Wolfman.

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:

This doesn't guarantee robustness, but it's a good start! Turn in your test cases; they may help us grade your work (read: give you the maximum possible amount of credit).

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 except the first one 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 the last three 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:

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.