Page History

...

1. Tricky code should not be commented but rewritten. Code should be self documenting
2. Code that parses special input strings (e.g, comma delimited) should provide examples of valid strings in comments
3. Use // for all non-JavaDoc comments, including multi-line comments
4. Comments should be in English
5. Comments should be indented relative to their position in the code
6. All public classes and public and protected functions within public classes should be documented using the Java documentation (javadoc) conventions

Libraries

1. For string operations, org.apache.commons.lang3.StringUtils must be used. For operations not covered by org.apache.commons.lang3.StringUtils, the facade com.cloud.utils.StringUtils must be used.

Database Conventions

1. All SQL keywords are all-caps
2. Naming:
   1. Table and column names are lower case with underscore separating words
   2. Indices (including UNIQUE) are lower case of the form i_<table name>_<column name>
   3. Foreign key constraints are of the form fk_<table name>_<foreign table name><foreign column_name>
3. All CREATE TABLE’s should have the corresponding DROP TABLE IF EXISTS at the top of the file.
4. Database engine must always be InnoDB. Charset should always be UTf8
5. Primary keys are always bigint unsigned NOT NULL UNIQUE AUTO_INCREMENT
6. Tables intended for operational purposes, usually transient data should be prefixed with op_ (e.g., op_lock)
7. Columns should always be commented unless obvious
8. Examine each column to choose your indexes. More indexes can mean more tablespace usage (but this is usually trivial) but better performance. More indexes also increase the possibility of deadlocks.

...