Flow Coding Guidelines (PSR-2) on one page
<?php
Prefer strict types declare(strict_types=1); Capture the joy of coding as you
namespace Acme\TestPackage; create excellent web solutions.
Namespace starts with vendor Enjoy coding. Enjoy Flow.
name followed by package key /*
* This file is part of the Acme.TestPackage package.
(name) and subparts as needed
*
* (c) Whoever wrote this
*
* This package is Open Source Software. For the full copyright and license
* information, please view the LICENSE file which was distributed with this
One use statement per line. * source code.
One use statement per */ Description of the class. Make it
namespace. as long as needed, feel free to
Order statements alphabetically. use Acme\TestPackage\Service\FooGenerator;
explain how to use it
Don't import namespaces unless use Neos\Flow\Annotations as Flow;
you use them /**
* Here goes the description of the class. It should explain what the main UpperCamelCase class name.
* purpose of this class is...
* Class names should be nouns.
No empty line between * @Flow\Scope(”singleton”) In other packages, import \Acme\
DocComment and class, */ TestPackage\UniverseAnalyzer
member var or method class UniverseAnalyzer extends BaseClass implements SomeInterface and refer to it as
{ UniverseAnalyer
/**
* Some injected dependency
*
Use @var tag. Optional
* @Flow\Inject
description goes in the first List @Flow\* before other tags:
* @var FooGenerator
comment line followed by a @var, @param, @return, @throws,
*/
@api, @since, @deprecated
blank comment line protected $someDependency = null;
/**
* @var bool
*/
static protected $addictedToFlow = true;
Prefer relative namespaces, /**
unless Fully Qualified * Shows if you are a fan of Flow
*
Namespace is more readable * @var bool
*/
protected $fanOfFlow; Description of the method. Make
it as long as needed
/**
* A great method which shows how to indent control structures.
* Method names should be verbs
Indent with spaces * @throws \Exception
*/
public function analyzeUniverse(MyClass $object, array $data = []): void
{
$subObjects = $object->getSubObjects();
foreach ($subObjects as $subObject) {
/** @var $subObject MySubClass */
$subObject->doSomethingCool(); Use type hinting
}
Multiline conditions: if (isset($someArray['question']) Only use inline @var annotations
Indent them and add a extra && $this->answerToEverything === 42
when type can't be derived (like
indent to following code. Put the || count($data) > 3) {
$this->fanOfFlow = true; in an array of objects) to
boolean operators at beginning increase readability and trigger
} else {
of line throw new \Exception('We cannot tolerate that.', 1223391710); IDE auto-completion.
}
}
UNIX timestamp at time of
Param annotation: type, name,
/** writing the throw clause.
description if they provide
* This is a setter for the fanOfFlow property.
additional information over type *
hints * @param boolean $isFan true to mark a fan, false for a Zend follower Write what went wrong, give
* @return void since this is a setter, duh helpful details and give a hint for
*/
@return annotation with type, public function setFanOfFlow(bool $isFan): void a possible solution.
only if it provides additional {
information over the type hint $this->fanOfFlow = $isFan;
} Setter methods should start with
“set”.
/**
* As simple as it gets – a boolean getter.
* Methods returning boolean
* @api values should start with “has” or
@api tag defines public API */ “is”. Other getters should start
public static function isAddictedToFlow(): bool with “get“.
{
Opening brace on the next line return self::$addictedToFlow;
}
Full PSR-2 Coding standard https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
Also check out the latest documentation: http://flowframework.readthedocs.org/en/stable/TheDefinitiveGuide/PartV/CodingGuideLines/index.html
