Sweeping guidelines

  1. Don't introduce code provisionally. Only insert code that is being used for a purpose.
    • Corollary: Develop using vertical slices, instead of horizontal slices
  2. Each CL does one thing. Don't insert refactorings into functional changes and vice-versa.
  3. Aim for small CLs.
  4. Don't send out "try-things-out" CLs.
  5. Make CLs direct and concrete.
    • no unneccessary indirection; keep hierarchies shallow
    • put String constants directly in code instead of having unnecessary finals declared
  6. Prefer plain/idiomatic/obvious over clever.
  7. Name things!
    • 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

Particular considerations

  1. 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.
  2. Was equals considered?
  3. Was hashCode considered?
  4. Were exceptions considered? Are exceptions scoped precisely and accurately?
  5. Was toString considered? toString is helpful for testing and debugging.
  6. 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.
  7. Please provide sufficient tests.
  8. BufferedImage is TYPE_INT_RGB.
  9. Gui code should be done with SwingUtilities.invokeLater() such that SwingUtilities.isEventDispatchThread() returns true.
  10. 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 Random.
    • This allows the class to be tested with repeatable results
  11. Was use of System.out and System.err considered? Be very selective about putting information on these channels. Quite possibly never use them for communicating information.
  12. Watch out for autoboxing and varargs producing undesirable behavior.
  13. Consider public and final modifiers on classes and methods.
  14. Add javadoc.

Detailed Google Java guide