- Don't introduce code provisionally. Only insert code that is being used for a purpose.
Each CL does one thing. Don't insert refactorings into functional changes and vice-versa.
Aim for small CLs.
Don't send out "try-things-out" CLs.
Make CLs direct and concrete.
- Corollary: Develop using vertical slices, instead of horizontal slices
Prefer plain/idiomatic/obvious over clever.
- no unneccessary indirection; keep hierarchies shallow
- put String constants directly in code instead of having unnecessary finals declared
- make specific exception classes
- don't use "abstract" in class name
- don't use "impl" in class name
- name sub-blocks of code by converting to methods
- Is the code thread safe? Read your code and check whether your code behaves well when multiple methods of an instance are executing simultaneously. Avoid setters to make classes immutable.
- Were exceptions considered? Are exceptions scoped precisely and accurately?
toString is helpful for testing and debugging.
- Does the code call
exit? Don't call
exit as it prevents code from being made into a library as well as no longer having an understood shutdown sequence.
- Please provide sufficient tests.
- BufferedImage is
- Gui code should be done with
SwingUtilities.invokeLater() such that
- If a class uses
Random, have the instance of
Random passed into the class constructor or
init method, rather than the class creating its own instance of
Was use of
- This allows the class to be tested with repeatable results
System.err considered? Be very selective about putting information on these channels. Quite possibly never use them for communicating information.
Watch out for autoboxing and varargs producing undesirable behavior.
final modifiers on classes and methods.
Detailed Google Java guide