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:
-Wall
flag enabled. (Notify us of errors in our code.)
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
touch
ing 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.