Both implementor and reviewer must be very careful. 
Please check that you understand all of the above.

For each code task (no matter whether it is a library, external feature, bug fix...), should pass the following check list:

 * code 
  * The code style is correct to our convention. 
  * The code is easily readable. 
  * There are no fake !JavaDocs (!JavaDocs without useful information).
  * The java-doc is complete enough. 
   * For each element, the !JavaDoc should describe clearly what is it (if this is not easy, then probably the design is bad)
  * It causes '''0''' errors. 
  * It causes '''0''' warnings.
  * The @!SuppressWarnings annotation is used only if really needed.
   * I know 3 cases for it - 
    * unused, when something is used only by reflection
    * synthetic-access, when you want to touch something internal with inner class (although in many cases this may be avoided)
    * unchecked, when you are doing something complex with generic (note that this is also avoidable in many cases)
  * No inaccurate, or unclear XXX and TODO tags
  * It should not break other code (ensured by their tests).
  * other suggestions?


 * design
  * It is documented 
   * (not only in the code). 
  * It is simple and understandable.
  * It is easy to use.
   * (using it requires less work / small code)
  * It is error proof (hard to use it in a wrong way)
   * The compiler prevents most errors.
    * (it is better to have an abstract getKind() instead of forcing implementors to call setKind at construction)
    * ('''final''' may also help)
   * Most of other errors cause an exception
    * (defensive programming helps here)
  * When a library is used, it is used correctly.
  * There are no representation exposures.
  * There are no GOD (very long) methods.
  * There are no GOD (very long) classes.
  * The coupling is low.
  * No magic numbers (and strings)
  * No array members.
   * (unless there is really a reason)
  * No public instance fields.
  * No public non final fields
  * It has high cohesion.
  * (see http://en.wikipedia.org/wiki/Cohesion_(computer_science) )
  * It has low coupling.
   * (see http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 )
  * It is possible to state in one sentence what every class or member is/does.
  * Classes and members are named correctly.
  * Every class (or attribute) is self responsible and self complete.
  * No code duplication (copy paste).
  * It is easily testable.
   * (when not, testing helpers are provided to make it such).
  * No other kind of smells.
 * It has good package structure.
 * It is logging correctly.
 * It has adequate error handling.
 * No premature optimization.
 * No premature abstraction.

 * tests
  * It has automatic use case tests, '''before''' implementing.
   * (they are very good to demonstrate the design for a library)
  * If it has demos, the demos are actually tests with main method.
   * (demos should be done at design time!)
  * It has enough unit tests to ensure its correctness 
   * (listed at design time, passing at implementation time) 
  * It has enough integration tests 
   * (listed at design time, passing at implementation time) 
  * It has enough system tests 
   * (listed at design time, passing at implementation time) 
  * It has written scenarios for manual testing
   * (when it is an external feature or a bug)
  * The tests had code coverage
   * (good code coverage does not mean good tests, but bad code coverage means bad tests)

 * other:
  * Enough information should be provided in the backlog.