Code_Rules

We don't want to inhibit a developer's style too much, but we do have some guidelines we want to be followed.

1. USE A TAB CHARACTER WHEN INDENTING!!! Don't use spaces.
2. Try to be descriptive with variable names, and don't use acronyms/abbreviations (This rule is not VERY important, but should be followed as much as possible).
3. Follow the variable naming convention (This is for consistency in the code, it makes it easier to read).
   1. Public, non-static, non-final variables just start with a lower case letter and use camel case (yourVariableName).
   2. Public, static, non-final variables start with a k and use camel case from there (kYourVariableName).
   3. Public, non-static, final variables should generally not be used (If you find an instance where one is required, I will be very suprised).
   4. Public, static, final variables are all caps with works seperated by underscores (YOUR_VARIABLE_NAME).
   5. All private variables are like public ones, but start with m_ or M_
      1. Non-static, not-final: m_yourVariableName
      2. Static, non-final: m_kYourVariableName
      3. Non-static, final again should not be used.
      4. Static, final: M_YOUR_VARIABLE_NAME
   6. All protected variables are like public ones, but start with n_ or N_
      1. Non-static, not-final: n_yourVariableName
      2. Static, non-final: n_kYourVariableName
      3. Non-static, final again should not be used.
      4. Static, final: N_YOUR_VARIABLE_NAME
4. Classes, Interfaces, and Enums are upper case then camel case (YourClassName).
5. Methods are lower case then camel case (yourMethodName()).
6. Do NOT make a class or method final.
7. Try to avoid throwing errors as a result of the limitations of the simulator. Use Simulator.fixme() and Simulator.err() instead.
8. For messages that might not be important the user, use Simulator.msg(), Simulator.fixme(), or Simulator.err().
9. Javadoc every class and method!
10. Don't make variables public and non-final unless you have a very good reason, use getters and setters (or better yet, properties) instead.
11. When declaring/modifying multiple variables, try to make the modifiers, type, name, and = line up.
12. It is up to you as whether you want to use wildcards in imports (imports are just syntactical candy anyway).
13. Try to put spaces around operators (a + b or a = b, as opposed to a+b, or a=b).
14. If there is something you need to do to make the code look better, do it (this takes precedence over all other rules).