Computer Sciences Dept.

CS 367: Introduction to Data Structures

Spring 2005
Instructor: Prof. Mary Vernon

Tues. & Thurs. 1:00-2:15pm, 1221 CS


Course Grades

CS 367 grades will be computed from scores on five programming assignments, approximately 10 short homework assignments, two midterm exams, and a final exam.

The approximate weight on each component will be as follows:

  • 30% Programming assignments
  • 15% Short homework assignments
  • 30% Midterm Exams (15% each)
  • 25% Final Exam

More details about the programming assignments and exams are given on the 367 Assignments and Exams web page.


Grading Criteria for Programming Assignments

Your program grades will be based on:

  • correctness
  • efficiency
  • style
  • test coverage

Correctness


Correctness includes programming "to specification". This includes satisfying both the functional specifications and the interface specifications given in the programming assignment. For example, if you are given a signature for a method that you should implement, you should not change the signature. That is, you should not change any of the following: the name of the method, the access (public or private), the return type, the number of parameters, the types of the parameters, the throws clause.

Similarly, if you are told to use specific names for your files, or to have your program produce specific output, use the names and the output exactly as specified -- using similar names or output will result in loss of correctness points.

Efficiency


Efficiency is an important aspect of good programming, so inefficient code may be penalized.

Style


Style considerations include useful comments that help in program readability, indentation that reflects program structure, and meaningful names (e.g., for methods, fields, and variables). Every method should have a comment that defines what its parameters are, briefly what it does, and (for a non-void method), what it returns. You should not comment every line of code, but you should include comments to explain "chunks" of code.

See DemoStyle.java for an example of code that follows these style rules.

Test Coverage


Testing is one of the most important aspects of programming. You should design tests so that every statement in the code is executed at least once. You should also test "boundary" cases, such as applying operations to empty data structures or to structures that contain a single value or to unexpected input data such as negative numbers. You should also test error conditions (i.e., if your code throws exceptions or produces error or warning messages under certain conditions, you should be sure to test those conditions -- use a "try" block to catch exceptions so that your test program doesn't halt).

In general you should write the tests as if you are working at a company for a customer who needs for code that will work correctly for any valid input and will print sensible error messages for any invalid input that might be given to it by any user "in the field", unless otherwise stated in the program specification.

It may be useful when designing your test code to think about what tests you would write if you were testing code that someone else has written.

It is important to design test code to produce output that makes it clear whether there are errors in the code. A good approach is to have the test code produce output only if the code being tested behaves in an unexpected way (and in that case, the test code should report the unexpected behavior).

 
Computer Sciences | UW Home