Coding Guidelines

• Use standard Java style. In particular:
  • Four spaces indentation.
  • Curly braces on same line.
  • Avoid prefixes.
  • If in doubt, look at the existing code.

• All names should be meaningful.

• EVERY class should have a JavaDoc description. If a method/field is not obvious from it’s name, it should also have JavaDoc (though it’s preferable that the name explains it).

• Include an @author tag in all new files. If making significant changes to an existing file, add yourself as an @author.

• Dependencies on libraries and between packages matter. If you’re importing from a package
  that is not already used in the current package, check it makes sense in the ArchitectureOverview.

• All functionality and bugfixes should be accompanied by tests. Depending on what it is, choose
  an appropriate granularity of test (i.e. it may not always make sense to use a fine grained unit
  test, you could use a higher level acceptance test).

• No static mutable fields or singletons. Anywhere. Ever.
  • Simple constant values are OK (e.g. public static final String).
  • Avoid ThreadLocals.

• If you are making a change that affects end-user functionality, please update the user documentation.

• Don’t check any large/binary files into source control (e.g. external jars, build outputs).

If in doubt, ask!