Developers who contribute to the project should follow a few guidelines.

Commits

Some contributors have a commit right to the symfony repository. In this case, they work in an forked branch of the code, and the merge is done by the core team before major releases.

• Always do granular commits, each related to a specific feature. Don't mix unrelated modifications in a commit, so that debugging (and reverting) can be easier.
• Use a descriptive label for your commit, with verbs in past tense. All the developers should understand what it does and why, and it should be short.
• Always provide the unit tests to validate the code you commit.
• Always document the functions and methods you add or modify (using phpdoc)
• For commits to a branch, prefix the commit message with the branch name. For example: "fabien: fixed trouble."
• If your commit closes a ticket in the bug tracker, suffix your commit message with the text "(closes #1234)", where "1234" is the number of the ticket your commit fixes.
• If you commit someone else code, suffix your commit message with the text "(patch from abc)", where abc is the trac login of the patch writer.

Coding practices

The golden rule: Imitate the existing symfony code

• Never use tabulations in the code. Indentation is done by steps of 2 blanks.
• Don't put spaces after an opening parenthesis and before a closing one.

   if ($reqvalue == _getRequestValue($name))    correct
   if ( $reqvalue == _getRequestValue($name) )  incorrect
  

• Use camelCase, not underscores, for variable, function and method names.
• Use underscores for helper functions name (only for symfony 1.0 stuff).
• 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.
• 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.

  function fooFunction()
  {
    if (condition2 || condition3)
    {
      statement1;
      statement2;
  
      return 1;
    }
    else
    {
      defaultaction;
    }
  
    return null;
  }
  

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

    // space first, with no full stop needed
  

• Avoid evaluating variables within strings, instead opt for concatenation

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

• Use lowercase constants: false, true, null
• To check if a variable is null or not, use the is_null() function
• When comparing a variable to a string, put the string first:

     if (1 == $variable)
  

• A phpdoc block begins with a single line ending with a point. All @... statements do not end with a dot:

     /**
      * Notifies all listeners of a given event.
      *
      * @param sfEvent A sfEvent instance
      *
      * @return sfEvent The sfEvent instance
      */