Coding standards

There are many fine, readable coding standards and formats. This coding standard is not necessarily better than others that we could be using, but for consistency, all new code should stick to the standards that have been used for code already written.

This is an initial cut at defining, in words, what is already in use. This may well require some adjusting and/or additions before all of the questions are answered. When in doubt, follow the format that is already in the code.

• Be sure you have whatever editor you're using configured to insert spaces only, and not tabs. Use of tabs cause problems for other developers who have differing tab-width settings. Never use tabs. Always use spaces.
• Indentation: 2 spaces per level.
• Do not exceed 80 characters per line. Limiting line length to 80 characters allows viewing two side-by-side full pages of code on reasonable size screens.
• Use braces for every block, even when there's only one statement in the block.
• The opening brace for a function or block is placed at the beginning of the "next" line, and aligns vertically with the first character of the line above. It also aligns vertically with its matching closing brace.
• There should be one space before and after each operator.
• There should be one space before an opening parenthesis and no space after it.
• Typically there is no space before a closing parenthesis.
• Space after a closing parenthesis depends on the standard for the following token. For example, if an operator such as && follows the closing parenthesis, there should be one space between the closing parenthesis and the operator, but if another closing parenthesis follows, there would be no space between the two closing parenthensis.
• Comments, comments, comments. Every small block of code should be commented in detail, and every larger block (e.g., function) should be documented as to its overall purpose and inputs and outputs. Functions should use qooxdoo's modified JavaDoc-style commenting. The big modification is that the expected type (or types) of the parameters must be specified in the documentation (in a defined format) since variables are not strongly typed in JavaScript and no type is specified in the parameter list.
• Comments should generally be full sentences, using proper English grammar and capitalization. There are exceptions, where only a fragment is appropriate, but think about your commenting and try to make it as highly readable as possible.