Coding Standards

Warning: You are browsing the documentation for Symfony 2.6, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

Coding Standards

When contributing code to Symfony, you must follow its coding standards. To make a long story short, here is the golden rule: Imitate the existing Symfony code. Most open-source Bundles and libraries used by Symfony also follow the same guidelines, and you should too.

Remember that the main advantage of standards is that every piece of code looks and feels familiar, it's not about this or that being more readable.

Symfony follows the standards defined in the PSR-0, PSR-1, PSR-2 and PSR-4 documents.

Since a picture - or some code - is worth a thousand words, here's a short example containing most features described below:

        1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
        <?php

/*
 * This file is part of the Symfony package.
 *
 * (c) Fabien Potencier <fabien@symfony.com>
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

namespace Acme;

/**
 * Coding standards demonstration.
 */
class FooBar
{
    const SOME_CONST = 42;

    private $fooBar;

    /**
     * @param string $dummy Some argument description
     */
    public function __construct($dummy)
    {
        $this->fooBar = $this->transformText($dummy);
    }

    /**
     * @param string $dummy Some argument description
     * @param array  $options
     *
     * @return string|null Transformed input
     *
     * @throws \RuntimeException
     */
    private function transformText($dummy, array $options = array())
    {
        $mergedOptions = array_merge(
            array(
                'some_default' => 'values',
                'another_default' => 'more values',
            ),
            $options
        );

        if (true === $dummy) {
            return;
        }

        if ('string' === $dummy) {
            if ('values' === $mergedOptions['some_default']) {
                return substr($dummy, 0, 5);
            }

            return ucwords($dummy);
        }

        throw new \RuntimeException(sprintf('Unrecognized dummy option "%s"', $dummy));
    }

    private function reverseBoolean($value = null, $theSwitch = false)
    {
        if (!$theSwitch) {
            return;
        }

        return !$value;
    }
}
    

Structure

Add a single space after each comma delimiter;
Add a single space around binary operators (==, &&, ...), with the exception of the concatenation (.) operator;
Place unary operators (!, --, ...) adjacent to the affected variable;
Always use identical comparison unless you need type juggling;
Use Yoda conditions when checking a variable against an expression to avoid an accidental assignment inside the condition statement (this applies to ==, !=, ===, and !==);
Add a comma after each array item in a multi-line array, even after the last one;
Add a blank line before return statements, unless the return is alone inside a statement-group (like an if statement);
Use just return; instead of return null; when a function must return void early;
Use braces to indicate control structure body regardless of the number of statements it contains;
Define one class per file - this does not apply to private helper classes that are not intended to be instantiated from the outside and thus are not concerned by the PSR-0 and PSR-4 autoload standards;
Declare class properties before methods;
Declare public methods first, then protected ones and finally private ones. The exceptions to this rule are the class constructor and the setUp and tearDown methods of PHPUnit tests, which should always be the first methods to increase readability;
Use parentheses when instantiating classes regardless of the number of arguments the constructor has;
Exception message strings should be concatenated using sprintf.

Naming Conventions

Use camelCase, not underscores, for variable, function and method names, arguments;
Use underscores for option names and parameter names;
Use namespaces for all classes;
Prefix abstract classes with Abstract. Please note some early Symfony classes do not follow this convention and have not been renamed for backward compatibility reasons. However all new abstract classes must follow this naming convention;
Suffix interfaces with Interface;
Suffix traits with Trait;
Suffix exceptions with Exception;
Use alphanumeric characters and underscores for file names;
For type-hinting in PHPDocs and casting, use bool (instead of boolean or Boolean), int (instead of integer), float (instead of double or real);
Don't forget to look at the more verbose Conventions document for more subjective naming considerations.