Coding standards

The coding standards for this project are still in flux. Most of the grammar specified below is probably stable; however, there are still some holes where standards have not been defined yet. Also, current project files contain some code that does not yet follow this standard.

Special thanks to Drupal, where some of their standards have been adopted here. It is likely that many of the holes in this current draft will be eventually filled by the Drupal grammar.

Contents

• Indenting and Whitespace
• Operators
• Casting
• Naming Conventions
• Commenting
• Function Calls
• PHP Code Tags
• Semicolons

Indenting and Whitespace

Tabs should be used to indent code.

Lines should have no trailing whitespace at the end.

Indenting of functions/classes/control-structures, should follow the Kernighan & Ritchie style. Eg:

CORRECT:

INCORRECT:

INCORRECT:

Operators

All binary operators (operators that come between two values), such as +, -, =, !=, ==, >, etc. should have a space before and after the operator, for readability. For example, an assignment should be formatted as $foo = $bar; rather than $foo=$bar;. Unary operators (operators that operate on only one value), such as ++, should not have a space between the operator and the variable or number they are operating on.

Casting

Put a space between the (type) and the $variable in a cast: (int) $mynumber.

Naming Conventions

Items should be formatted according to the following rules:

Type:	Format to use:	Example:
Classes	Mixed-case with words seperated with an underscore	Foo_Bar
Function/Method	Lowercase with words seperated with an underscore	foo_bar($baz)
Variables/Properties	Camel-case, starting with a lowercase letter	$fooBar
Constants	UppercaseFOO_BAR

Also, functions/methods, which are for the internal use of the class or connected classes should start with an underscore (_). These are not necessarily methods declared as private but ones, which are only used internally and not part of a public API.

Commenting

All docblocks should be formatted according to the Doxygen rules. All Doxygen tags should be in lowercase unless specified differently in the Doxygen documentation. Tags should use the @javadoc style (ie. using the @ symbol) Good docblock documentation for all classes, methods and properties is strongly encouraged.

Inline comments should use the double-slash format (//) and should start with a capital letter and end in a fullstop. Perl-style comments (using #) should not be used.

Function Calls

Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon. Here's an example:

$var = foo($bar, $baz, $quux);

As displayed above, there should be one space on either side of an equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, more space may be inserted to promote readability:

$short                  = foo($bar);

$long_variable         = foo($baz);

PHP Code Tags

Always use to delimit PHP code, not the shorthand, . This is required for ImpactCRM compliance

Semicolons

The PHP language requires semicolons at the end of most lines, but allows them to be omitted at the end of code blocks. Impact coding standards require them, even at the end of code blocks. In particular, for one-line PHP blocks:

-- YES

-- NO