CSE logo University of Washington Computer Science & Engineering
 CSE 326 Winter 2010
  CSE Home    326 Home   About Us    Search    Contact Info 

Assignments & Exams
 Projects
 Written Homeworks
 Midterm Exam
 Final Exam
Administrative
 Home
 Annoucement ArchiveCSE only
 Message Board
 Anonymous Feedback
Lectures
 Calendar & Slides
Handouts
 First Day Handout
Policies
 General Guidelines
 Grading Policies
 Programming Guidelines
 Written HW Guidelines
Computing
 Unix Basics
 LaTex Info
   

Programming Assignment Guidelines

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 these steps without problems before submitting your code:

  • Compile without warnings or errors. (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 writeup.
This doesn't guarantee robustness, but it's a good start! Turn in your test cases; they may help us grade your work better (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 (or fails). 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 Java allows 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, a few months later).

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!

Using Java Class Libraries: Unless specifically approved or directed to, you should not use Java class libraries in your programming assignments. In otherwords, we should not see the words "import" in your code.

CSE logo Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to rea]