We have posted a number of answers, clarifications and best practices for the component competition process in various forum threads. The following, along with our updated Reviewer Guidelines , compiles these updates into one definitive list, and it should be considered required reading for component competitors and reviewers. This document will be updated as needed over time — to discuss the points below or raise more questions, please visit the Software Forums.

• Scoping New Classes
  If you add helper methods or classes, you should scope them as narrowly as possible while maintaining their useability. For example, if a helper class absolutely has to be public (to span across packages), then it is fine to make it public.
• Resource Management
  Components should manage their resources wisely. Just because Java and .NET use garbage collection doesn't mean that resource deallocation can be ignored. For example, a component that uses JDBC should close its Connection, PreparedStatement and ResultSet objects when they are no longer needed. If these references are allowed to leak, they might stick around in the VM until it's restarted. A common mistake is to create a Connection, PreparedStatement, and ResultSet, and then return the ResultSet to the caller, immediately leaking the first two objects.
• JDBC Connection Management
  JDBC Connection objects should *never* be cached. Creating and closing connections every time you need them rarely results in a performance drop, since most applications will be using a connection pool.
• Creating SQL Statements
  Prepared Statements should be used almost exclusively. The cases where dynamic SQL needs to be used are exceedingly rare. The performance degradation incurred by using dynamic SQL can be severe and will cause difficulties for all applications accessing the database. Dynamic SQL also introduces security issues (SQL Injection) that are alleviated by the use of Prepared Statements.
• Absolute Paths
  Components should not require absolute paths in their configuration, and neither should test cases.
• Hardcoded Paths
  Components should not require hardcoded paths in their configuration, and neither should test cases.
• Environment Dependencies
  You should be very careful that you do not introduce operating system or file system dependencies into your code and test cases. You should also check whether a submission you are reviewing has those dependencies. Examples include assuming that the file system is or is not case sensitive, assuming that files can or cannot be marked executable, or that there will not be extra files in the testing directories (a common case when the component is checked out of CVS or Subversion).
• Localization
  Locale dependencies are another major issue. You should make absolutely sure that all strings are formatted for the proper locale. This is a particularly big problem when creating documents that have to conform to a specific standard: if a locale happens to contradict the standard, the component won't work in it. A common problem is generating locale-specific string representations of floating point numbers for a format that assumes that the decimal separator is a dot. Any locale where the decimal separator is a comma will break the format.
• Testing
  • Separating Tests
    Testing for multiple issues in a single function is poor practice, since when one of the checks fails JUnit / NUnit will count the whole block as a failure. This doesn't pinpoint the problem to a tester, and more importantly it results in a score that does not reflect how many tests the submission truly passed.
  • Test Location
    All your tests should be placed in the base test directory (generally src/java/tests/main/package/name for Java, or src/csharp/tests/Main/Package/Name for .NET). If you wish to separate your tests for each package in the design, you may do so. However, in that case you are responsible for ensuring that all your tests end up in your development submission. Competitors should never place tests in the Accuracy, Stress, or Failure directories. Those directories are for reviewer tests only.