CS 367:
Introduction to Data Structures
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).
|