Skip to content

Coding Conventions

Please be careful about not including trailing whitespace. You can configure your editor to show you whitespace.

Whitespace rules

  • Indent with tabs (ok to align with spaces if a statement spans multiple lines, e.g. a long soql query). Try changing your tab width from 2 spaces to 8 spaces; code should look good with both.
  • Tabs should never follow non-tabs on a line
  • Blank lines shouldn't have any whitespace
  • No space between unary operators and their operands (y = !x, y = -x, if (!x) {)
  • Spaces between binary operators and operands (y < x, y % x, y / x)
  • Give conditions space: if (true) {
  • Opening braces don't get their own line, nor do closing braces before else/else if statements; only closing braces get their own line
if (true) {
} else {
}

Style Conventions

  • Include a C++-style // line comment before each function describing what the function does. Comments can span multiple lines, but must be multiple line comments rather than /* block comments */. Comments can include light formatting using markdown; see docco docs.
  • Include optional braces
if (true) {
   doOneThing();
}
  • Class names use UpperCamelCase ( Good: Beer, BeerKeg; Bad: beer, beer_keg, Beer_Keg)
  • Methods and variables use lowerCamelCase ( Good: beer, beerKeg; Bad: Beer, sBeer (or other weird Hungarian notation))
  • SOQL keywords (SELECT, FROM, WHERE, etc.) are in all caps
  • Underscores between words in custom objects and fields (Beer_Keg__c)
  • Prefer object initializer syntax for SObjects (new SObject(Field = value, Field2 = value2))

Javascript Conventions

  • In JavaScript, one definition per var
var x = 1;
var y = 2;

Here's an example of things that you might need to fix:

Formatting Fixes

String Constant Rules

Guidelines on when to replace strings in code with constants. Also see related wikipedia article.

  1. If it doesn't make the code easier to maintain, by neither improving readability nor reducing the likelihood of future bugs, don't do it.
  2. If it makes the code harder to maintain by impairing readability, and does not reduce the likelihood of future bugs, definitely don't do it.
  3. If it improves maintainability by improving readability, do it.
  4. If it improves maintainability by both improving readability and reducing the likelihood of future bugs, definitely do it.
  5. If it improves maintainability by reducing the likelihood of future bugs, but impairs readability, maybe do it.