Style Guide

Spelling:
- Names are spelled camel-like, whereEachNewWordStartsWithCapital.
- Type names start with a capital,
  and each sub-type name starts with an abbreviation of the type
  (allows for look-up of type hierarchy via auto completion/listing).
- Method names start lower case and begin with a verb.
- Variable names start lower case.
  Parameters should start with 'p' to avoid confusion with
  local variables or fields.

Formatting:
- A block is surrounded by braces, e.g., if (...) { ...block... }.
- A function call has no whitespace between function name and parenthesis,
  e.g. func()...
- No trailing whitespaces.

Compilation:
- Warnings are taken serious, and problems should be fixed if possible.
  (When it becomes to many, we can't see the important ones anymore.)
- Errors are to be eliminated as soon as possible.
  (Annoying.)

Version Control:
- Commit early, commit often, and
  split the commits into reasonable changesets.
- In order to avoid EOL problems caused by Unix/Windows/Mac, let's run
  find ./ -name "*" -exec svn propset svn:eol-style native {} \;
  from time to time.
- If possible (this will definitely not always be the case)
  commit in a way that the project compiles after each commit.
  This will ease automatic regression testing a lot...
- For large chunks of whitespace/indentation changes,
  commit the whitespace changes and the code changes via separate commits.

Directory Structure:
- lib/           libraries and executables
- lib/native/    architecture-specific

File and Class Names:
- For a set of names of concepts (e.g., of files, classes),
  the prefix order induced by the names should
  represent the semantic relation and structure of the concepts.

Coding:
- Prefer iterators over List.get(int).
- Before implementing equals() for an AbstractElement,
  think if you can cache and reuse such objects.
