Java Tips
The best source of tips for making your Java better is "Effective Java" by Joshua Bloch. There are a couple of copies floating around the research group. Read them over and over again - the advice doesn't go off.
If you're stuck as to why any of these are important, Jim can supply you with examples of times he got each of them wrong and it came back to bite him.
See also Java Howto
Contents |
Cleverness belongs in your science, not in your programming
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
Brian W. Kernighan
Write idiomatic Java
This basically means using constructs that people expect to see. It's more important that your code can be understood by others than it running slightly faster, using fewer lines, or demonstrating your cleverness.
Use design patterns
Design patterns are standard ways to solve standard problems, and as such they help somebody to understand how you've solved a problem, thereby helping them to understand the problem itself. There's a Java design patterns book floating around the group - help yourself.
Document your use of design patterns
... and don't be subtle. If you're using the Factory object pattern to create your Foo objects, call the class FooFactory, and write "This class implements the Factory object pattern".
DEWISOTT naming
Classes and methods should Do Exactly What It Says On The Tin. Obvious names are better than accurate names and more important even than javadoc. Don't write a method called Cat.excoriate() when you could write Cat.skin().
Exception Handling
This advice is all repotted from Effective Java, in shorter form.
When to throw, What to throw
Catchable Exceptions are any Exception that doesn't extend RuntimeException. Never throw a catchable Exception from a public method unless you have any expectation that the caller of the method will do something other than log it. Instead, wrap it in a RuntimeException: -
... try { Foo.openNetwork(); catch(IOException e) { throw new RuntimeException("Failed to open the Foo network because of "+ e.getMessage(), e); } ...
When to define your own exceptions
The preadvice for this point is that you should use existing Exception types if there's one available. A null has been incorrectly passed in to a method? IllegalArgumentException. Methods have been called in the wrong order? IllegalStateException. And so on.
Apart from this, there are two circumstances in which it's worth defining your own exception types: -
1 ) You want / need to supply additional structured information with the exception.
A good example here is a ParsingException that includes row and column indices for the error.
2 ) You can imagine someone wanting to handle your exception differently than they would a generic exception.
If the exception is just likely to be logged, or fed directly back to the user, there's no point defining your own exception type - it's just more code for you and more boilerplate catch clauses for people who use your code.
Use the J2SE APIs unless you've got a really good reason to use an alternative
Main candidates here are logging and regular expressions, both now included in J2SE.
Use utility libraries
It's odds on that your wheel will be squarer than the one in jakarta commons.
Don't use clogging
Having said that, Commons-logging is considered harmful, just use Log4J.