Our basic style guide for Java is to use Sun's Java guide http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html, but we do have a few subtle differences.
If you deviate from these conventions, be prepared to explain why.
White space
1 space after control statements (if (foo) instead of if(foo)), before brackets (if (foo) {), and between arguments (myFunc(foo, bar, baz).
no spaces after function names (void myfunction(), myfunction("foo"))
Reasoning: Consistency.
Design idioms
Avoid creating internal objects as much as possible. Favor dependency injection whenever possible. Make appropriate use of Guice.
Reasoning: Improves testability, improves encapsulation, and generally leads to a more maintainable system.
Naming
Treat acronyms as words. This means "HtmlParser" and not "HTMLParser". Java's standard libraries are inconsistent about this, but we shouldn't be.
Reasoning: Consistency.
Constants (static final members) and Enum values should always use an ALL_CAPS form.
Reasoning: Consistency, readability.
Use short, descriptive names for your classes and functions.
Reasoning: Readability.
Organization
Avoid treating classes as packages. This means you shouldn't have a lot of public inner classes. A separate public class is almost always better.
Reasoning: Maintenance, flexibility.
Blocks
Always enclose with braces. Declare block local variables inside the block at all times.
Reasoning: Reduces errors, does not waste memory allocating memory that is never used.
Indentation
Always use 2 space indents, unless you're wrapping a line in which case you should indent 4 spaces or indent to line up arguments. 4 space indentation is generally preferred, but line up arguments if it makes that bit of code more readable. Never use tabs.
Reasoning: Consistency.
Line wrapping.
We use a 100-column line width.
Reasoning: Consistency.
NOTE: This was changed in June 2008 from the previous 80 columns. Some older code may still be wrapping at 80 columns, but it should be updated over time.
Exceptions
If you're not doing anything meaningful with an exception, throw it to the caller. Wrapping with a RuntimeException is fine if it's an exception that is only going to occur in the event of a programming error rather than a logical error (i.e. the same reason why unchecked exceptions exist in the first place).
Reasoning: Swallowing exceptions makes debugging and testing difficult, and it hides errors.
Never catch generic Exception
Reasoning: Swallowing exceptions makes debugging and testing difficult, and it hides errors.
Standard Annotations
Use @Override where required, use @Deprecated when something is deprecated, but still functions, and use @SuppressWarnings only when it's impossible to eliminate the warning.
Reasoning: Readability, editor integration.
final
Use final whenever possible on all member variables.
Reasoning: Avoids missing initialization.
Documentation
Document your public interface well. This means that all non-trivial public and protected functions should include javadoc that indicates what it does, expected inputs, return values, exceptions thrown, and any implementation notes.
Reasoning: Other people need to use your code.
Do not include authorship information.
Reasoning: If we need to figure out who wrote it we have an SVN history.
Don't waste time with redundant and obvious comments. This means getters and setters probably don't need comments at all.
Reasoning: Readability.
Use the notation TODO: comment when leaving a comment about future work that needs to be done. This is automatically picked up by Eclipse and other editors, and it makes finding them useful. Don't put user ids or specific dates.
Reasoning: Editor integration, consistency.
scope
Limit scope as much as possible. If you have a member that is a private part of your interface, but that you need to get access to for testing (such as an internal constant), make it package private (default).
Reasoning: Improved encapsulation.
Testing
All non-trivial public classes should include a corresponding unit test. We use junit and easymock to make testing easier. Patches will be refused without corresponding test cases. Classes should have all feasible branches covered, any any branch that isn't covered must be explained in comments.
Reasoning: Reduces regression, Ensures functional requirements are being met, Debugging is annoying.