Recent changes to Code_Rules

WikiPage Code_Rules modified by Benjamin Pylko

Benjamin Pylko — Thu, 07 Jun 2012 18:34:55 -0000

--- v2
+++ v3
@@ -25,6 +25,6 @@
 +  Javadoc every class and method!
 +  Don't make variables public and non-final unless you have a very good reason, use getters and setters (or better yet, properties) instead.
 +  When declaring/modifying multiple variables, try to make the modifiers, type, name, and = line up.
-+  It is up to you as whether you want to use wildcards in imports.
++  It is up to you as whether you want to use wildcards in imports (imports are just syntactical candy anyway).
 +  Try to put spaces around operators (a + b or a = b, as opposed to a+b, or a=b).
 +  If there is something you need to do to make the code look better, do it (this takes precedence over all other rules).

WikiPage Code_Rules modified by Benjamin Pylko

Benjamin Pylko — Mon, 30 Apr 2012 17:48:30 -0000

--- v1 
+++ v2 
@@ -23,7 +23,7 @@
 +  Try to avoid throwing errors as a result of the limitations of the simulator. Use Simulator.fixme() and Simulator.err() instead.
 +  For messages that might not be important the user, use Simulator.msg(), Simulator.fixme(), or Simulator.err(). 
 +  Javadoc every class and method!
-+  Don't make variables public and non-final unless you have a very good reason, use getters and setters instead.
++  Don't make variables public and non-final unless you have a very good reason, use getters and setters (or better yet, properties) instead.
 +  When declaring/modifying multiple variables, try to make the modifiers, type, name, and = line up.
 +  It is up to you as whether you want to use wildcards in imports.
 +  Try to put spaces around operators (a + b or a = b, as opposed to a+b, or a=b).

WikiPage Code_Rules modified by Benjamin Pylko

Benjamin Pylko — Mon, 23 Apr 2012 15:41:55 -0000

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. + 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). + 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). + Public, static, non-final variables start with a k and use camel case from there (kYourVariableName). + Public, non-static, final variables should generally not be used (If you find an instance where one is required, I will be very suprised). + Public, static, final variables are all caps with works seperated by underscores (YOUR_VARIABLE_NAME). + All private variables are like public ones, but start with m_ or M_ 1. Non-static, not-final: m_yourVariableName + Static, non-final: m_kYourVariableName + Non-static, final again should not be used. + Static, final: M_YOUR_VARIABLE_NAME + All protected variables are like public ones, but start with n_ or N_ 1. Non-static, not-final: n_yourVariableName + Static, non-final: n_kYourVariableName + Non-static, final again should not be used. + Static, final: N_YOUR_VARIABLE_NAME + Classes, Interfaces, and Enums are upper case then camel case (YourClassName). + Methods are lower case then camel case (yourMethodName()). + Do *_NOT_* make a class or method final. + Try to avoid throwing errors as a result of the limitations of the simulator. Use Simulator.fixme() and Simulator.err() instead. + For messages that might not be important the user, use Simulator.msg(), Simulator.fixme(), or Simulator.err(). + Javadoc every class and method! + Don't make variables public and non-final unless you have a very good reason, use getters and setters instead. + When declaring/modifying multiple variables, try to make the modifiers, type, name, and = line up. + It is up to you as whether you want to use wildcards in imports. + Try to put spaces around operators (a + b or a = b, as opposed to a+b, or a=b). + If there is something you need to do to make the code look better, do it (this takes precedence over all other rules).