Software Design (CSC-223 97F)
Notes on Assignment 02
These are some of the general comments I had on your second assignment.
Most of you have the same or similar comments on your grade sheets, but
I may have forgotten to include some of them when appropriate.
- You don't need to restate the name of the class or method when writing
- You should separate the general commands from the "@tags" with a blank
line (or one that just has a
* on it).
- You can help verify that your program works correctly by writing
separate test programs for each of your classes.
- In general, you should make the fields in a class
Methods and code length
- Many of you have incredibly repetitious code, differing only in
a few variable names. You should turn such repetitious code into
a single method, and call it with different parameters.
- I was once told that no method should take significantly more than
one screen (24 or so lines). While this isn't quite true, you should
generally break up your larger methods into calls to smaller methods.
- Try to use meaningful names instead of single letters. Using
x for "probability of player one winning a serve"
- Upon further consideration, I've decided that you should do your best
to follow the naming standards set in the Java API.
- Class names always begin with an uppercase letter.
- Method names begin with a lowercase letter nad have mixed
- Variables names are all lowercase.
- Many of you need to do better error checking of input from the
command line (e.g., that the number
of arguments is correct and that they are in the appropriate range).
- In the future, you should be using exceptions for these types of problems.
- Don't encode results in integers unless you've defined constants
that correspond to those integers. Many of you return something
3 to indicate "player 1 won by shutout". That's
a pain to decode.
- Don't hard-code numbers like 1000 (the number of games). Use constants!
- Any classes that define
main() routines need to have
instructions for calling the class in the comments (and not just in
- I'd like to see more of you comment your right braces.
- It would be nice to see overall documentation for your program,
describing the relationships between classes.
- I was serious when I said that every four or so lines of code should
most likely have a high-level comment.
- I'd strongly recommend using the
// style comments
for your in-code comments. (This makes it easier to "comment out"
a block of code.)
- From now on, you should be using pre- and post-conditions.
- Include whitespace between separate methods.
- Don't be afraid to use some returns in your code, especially in long
- In general, right braces should be on lines by themselves, and
open braces should not be followed by anything.
- It's better if the differences in names come at the beginning, rather
than the end, of the names. E.g., use
b_player rather than
- Please make sure that all files (including
.html are readable).
- I didn't see very many citations, even though I know that many of
you got some assistance from Andrew or me or each other. Remember,
you need to cite such assistance.