About those painful bugs ...

When I describe the process I use to test a project, you should at least check this process yourself ...

The compile classes should be available at the root of your directory. During the marking process, I may :
* unjar your jar file (jar xvf ...)
* cd into your directory (all the file should be in your directory or in subdirectories and should not mess with my working directory !)
* run ' java Assignment myPath/canberraCenter.vot '
* del *.class
* javac *.java
Here is how I proceed to test your assignment (at least the first
steps of the process :
- I drag and drop your file from my Mail client to the directory in
which all the the other assignments are (i.e. all the jar are in the
same directory)
- jar xvf CG_A1_03_UyourID.jar
I hope that you understand that I don't expect your jar file to
explode into this directory, but into a subdirectory (or else, It
will put me in bad mood) !
- cd CG_A1_03_UyourID
(that is the famous previous subdirectory)
- java Assignment
This simple command should work well ...
Except if you had fun with packages ...
packages are important and should be used when needed (as
often as possible). Your Assignment class will certainly use
some packages ("import" statement) from the standard API or
from yourself ... BUT I don't think there is really any use in putting
your Assignment class into a package ("package" statement).
That class is not supposed to be used by anything else in your
jar file. The only side effect is that my testing protocol will be
suddenly stopped and I will have to look into your code in order
to check what special prefix I will have to add and from where in
the directory structure I will have to call that class with
something like ...
java that.is.quite.a.strange.name.for.a.package.Assignement
And I guess at that time I could get in bad mood too ...
- java Assignment myPath/canberraCenter.vot
and then they are still lots of funny things that you don't want to
know ... and then
- webbrowser README.html
At that point I am ready to look at your README file ... which of
course will be at the root of your subdirectory (you don't want me
to search in all your subsubsubdirectories in order to find the
explanation about where I should look for the explanation about
where I should look for the explanation ....
One last thing : your program will be tested under Unix (either
Linux or MacOSX) with a standard java version "1.4"

It could be a good thing to check your program on one of these
platform before you send it to me ... I am not rich enough to buy
45 different platforms and you all have access to DCS or
escience lab.

Catch the exceptions

Every time you have to deal with any sort of input you should catch the exceptions, because you'll never be able to entirely plan what could the user do

When you catch an exception ...

Take the opportunity to provide the user with a short manual (list of parameter, accepted range ...)

What a real user would do with my program ?

It is not the same to debug a program and to really use it with a purpose.

Use a spell checker !!!

Complete Java Doc ... : must include private field and methods

Spacing : tab or spaces ?

Anything for the spacing, but ... this wont be my choice ...

	static void setLowestBranchHeight(float height)    {
	if (height < LOWEST_BRANCH_ALLOWED) {
		firstBranchPosition = LOWEST_BRANCH_ALLOWED;
	} else if (height > HIGHEST_BRANCH_ALLOWED) {
		firstBranchPosition = HIGHEST_BRANCH_ALLOWED;
	} else {
		firstBranchPosition = height;
	}
	}