Skip to main content

Symfony Coding Standards


The golden rule: Imitate the existing symfony code

[1] Never use tabulations in the code. Indentation is done by steps of 4 blanks. For yml files 2 blanks should be used.

[2] Don't put spaces after an opening parenthesis and before a closing one.
if ($reqvalue == _getRequestValue($name)) correct
if ( $reqvalue == _getRequestValue($name) ) incorrect

[3] Use camelCase, not underscores, for variable, function and method names.

[4] Use underscores for helper functions name (only for symfony 1.0 stuff).

[5] Use underscores for option/argument/parameter names.

[6] Braces always go on their own line.

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

[8] 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.

[9] 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;
}

[10] All one line comments should be on their own lines and in this format.
// space first, with no full stop needed

[11] Avoid evaluating variables within strings, instead opt for concatenation es and string with a lot of substitution
$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

[12] Use lowercase constants: false, true, null

[13] To check if a variable is null or not, use the is_null() function

[14] When comparing a variable to a string, put the string first:
if (1 == $variable)

[15] A phpdoc block begins with a single line ending with a point. All @... statements does not end with a dot:
/**
* Notifies all listeners of a given event.
*
* @param sfEvent A sfEvent instance
*
* @return sfEvent The sfEvent instance
*/

Popular posts from this blog

SalesForce Single Sign On With Symfony

Introduction Single Sign-On is a process that allows network users to access all authorized network resources without having to separately log in to each resource. Single Sign-On also gives your organization the ability to integrate with an external identity management system or perform web based single sign on to Force.com. How Single Sign-On Works The high-level process for authenticating users via Single Sign-On is as follows: 1. When a user tries to log in—either online or using the API—Salesforce validates the username and checks the user’s profile settings. 2. If the user’s profile has the "Uses Single Sign-on" user permission, then Salesforce does not authenticate the username with the password. Instead, a Web Services call is made to the user’s single sign-on service, asking it to validate the username and password. 3. The Web Services call passes the username, password, and sourceIp to a Web Service defined for your organization. (sourceIp is the IP address that ori...

PHP Codesniffer standard for Symfony

I have created a standard for Symfony framework to use with PHP code sniffer. -Download and install PHP code sniffer http://pear.php.net/package/PHP_CodeSniffer -Check out the code from subversion http://subversion.assembla.com/svn/phpsymfony/Symfony%20Code%20sniffer%20standards -Copy the Symfony directory to the code sniffer standard directory -Put --standard=Symfony for validating the file using Symfony coding standards $ phpcs --standard=Symfony /path/to/code/myfile.php