Course Policies
CSE 373: Data Structures and Algorithms
The University of Washington, Seattle, Winter 2010
Effective learning requires that each student be actively engaged in the subject matter and activities of the course. The course is structured to foster that engagement in several ways, including working together as a community on in-class activities, involvement in laboratory activities, and appropriate challenges in assignments and the project.
 
All the students in CSE 373, the teaching assistant, and the instructor form a community. As a community, we can work together to help each other learn. The first step in allowing this to happen is for each person to be present at class meetings. Regular attendance in class is required, and systematic absences will have a direct effect on the class-participation part of the course grade.
 
As for most three-credit courses at the University of Washington, students are expected to devote approximately 9 productive hours to the course per week. Actual demands will vary with the material and individual student. Each student is required to stay up to date with assignments, in order for the class to work as a community.
 
Assignments must be completed by their due dates in order to be graded and receive credit. Except in rare circumstances, assignments turned in after the time due will not be graded and will not receive credit. This makes it essential that assignments involving programming be started early, so as to leave plenty of time to resolve computer issues or programming problems.
 
Each student will have an opportunity to work in a partnership on a miniproject to create a program that demonstrates a technique involving data structures and algorithms. Guidelines and a list of available options will be provided.
 
Except when explicitly permitted, students are expected to turn in their own individually produced solutions to homework problems. Turning in the work of another as one's own is considered as a serious form of academic misconduct. The University has strict rules and penalties that apply when evidence of such misconduct is found.
 
The following is a tentative formula for weighting the various course components for computing final grades:
  • Assignments: 30 percent
  • Project: 20 percent
  • Midterm I: 10 percent
  • Midterm II: 10 percent
  • Final: 20 percent
  • Participation: 10 percent (including quizzes, peer evaluations, and selected class activities)

 
Homework must be submitted on-time for full credit. There are heavy point penalties for work submitted late. This policy, being carried over from the previous offering under Dr. Suciu, is the following: 25 percent off if one day late, 50 percent off if two days late, 75 percent off if three days late, and 100 percent off if four or more days late.
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 or in the comments near the top of your main source file.
This doesn't guarantee robustness, but it's a good start!
Variable naming:
Variable names should be well-chosen. It is fine to use traditional names like i for loop indexing, and n for the numeric parameter of a mathematical function. However, variables, method names, and class names with less than obvious traditional meanings should be given easy-to-understand descriptive names, especially if their lexical scope in the program is large. For example, a name such as topMargin is suitable to represent the amount of vertical space in a display between the top of a panel and the beginning of its graphical content.
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!

updated January 11, 2010.