Coding Standards

Following coding standards is one of the easiest way for everybody to understand everybody's code.

Here's the golden rule: Imitate the existing code.

Never use tabulations in the code. Indentation is done by steps of 2 spaces:

<?php
class sfFoo
{
  public function bar()
  {
    sfCoffee::make();
  }
}

Don't put spaces after an opening parenthesis and before a closing one.

<?php
if ($myVar == getRequestValue($name))    // correct
if ( $myVar == getRequestValue($name) )  // incorrect

Use camelCase, not underscores, for variable, function and method names:

• Good: function makeCoffee()
• Bad: function MakeCoffee()
• Bad: function make_coffee()

Use underscores for option/argument/parameter names.

Braces always go on their own line.

Use braces for indicating control structure body regardless of number of statements it contains.

Siwapp is written in php5, so every class method or member definition should explicitly declare its visibility using the private, protected or public keywords.

Don't end library files with the usual ?> closing tag. This is because it is not really needed, and because it can create problems in the output if you ever have white space after this tag.

In a function body, return statements should have a blank line prior to it to increase readability.

<?php
function makeCoffee()
{
 if (false !== isSleeping() && false !== hasEnoughCafeineForToday())
 {
   canMakeCoffee();

   return 1;
 }
 else
 {
   cantMakeCoffee();
 }

 return null;
}

All one line comments should be on their own lines and in this format:

<?php
// space first, with no full stop needed

Avoid evaluating variables within strings, instead opt for concatenation:

<?php
$string = 'something';
$newString = "$string is awesome!";  // bad, not awesome
$newString = $string.' is awesome!'; // better
$newString = sprintf('%s is awesome', $string); // for exception messages and strings with a lot of substitutions

Use lowercase PHP native typed constants: false, true and null. The same goes for array(). At the opposite, always use uppercase strings for user defined constants, like define('MY_CONSTANT', 'foo/bar'). Better, try to always use class constants:

<?php
class sfCoffee
{
  const HAZ_SUGAR = true;
}
var_dump(sfCoffee::HAZ_SUGAR);

To check if a variable is null or not, use the is_null() native PHP function:

<?php
if (!is_null($coffee))
{
  echo 'I can haz coffee';
}

When comparing a variable to a string, put the string first and use type testing when applicable:

<?php
if (1 === $variable)

Use PHP type hinting in functions and method signatures:

<?php
public function notify(sfEvent $event)
{
  // ...
}

All function and class methods should have their phpdoc own block:

• All @... statements do not end with a dot.
• @param lines state the type and the variable name. If the variable can have multiple types, then the mixed type must be used.
• Ideally @... lines are vertically lined up (using spaces):

  <?php
  /**
   * Notifies all listeners of a given event.
   *
   * @param  sfEvent  $event  A sfEvent instance
   *
   * @return sfEvent          The sfEvent instance
   */
  public function notify(sfEvent $event)
  

Credits

This page is completely copied from the Symfony Project our favourite php framework. Thank you all the symfony creators and contributors.