Change to PSR-2?

Hi all,

PSR-2 is the PHP-FIG coding style guideline I will link to at the bottom.
I think we all agree that it is not the most beautiful thing in the world but in the end tools will do the formatting for us. I propose to change our coding style to PSR-2 simply for standard reasons. More and more packages follow it and doing the same is a good example and makes it easier for every one of us to work with third party packages as the coding style will be known. Before putting up a vote I would like to hear some opinions.

Here is PSR-2:


I think it’s a good idea to use the PSR-2. Even if I think that this standard recommendation does not look good all over. But as Christian already wrote, you can work with other packages (e.g. Symfony-Packages: Symfony Coding Standards) easier. And if there is already a standard, why should we not use it then?

1 Like

I agree to that but I also think that we should first highlight advantages and drawbacks of doing so and come up with a concrete plan of action (e.g. when to change it? and whether there are good tools for this).

Some advantages I can think of:

  • Less confusion when working with 3rd party code that follows the same standard
  • Possibly lower barrier for 3rd parties to use parts of Flow/Neos

Some drawbacks:

  • IMO some of the rules make the code less readable and cumbersome to work with
  • Changing the code style will affect all classes - no changes will apply to older branches without manual adjustments!

I wouldn’t write the styles the way as they are defined in PSR-2 if we were to write our own CGLs. But I rather take this one with all the tools and documentation / IDE configurations than bike-shedding a custom solution. After all we want an IDE and tools to do that automatically and reliably. PSR-2 in that way is a big advantage.

1 Like

Can you clarify that? Are you in favor of going for PSR-2 or not?

Good call @bwaidelich
I would target that change together with the namespace mumbo-jumbo. That will probably also break backportability anyway.

1 Like

Yes - but it still looks ugly :wink: I just wanted to say there’s not much reasoning about if we like that style or not. I doubt someone can say that you’re clearly more efficient using this or that style. In the end it’s about choosing something that’s widespread, supported and we can stop bike-shedding.



I personally also very much dislike the PSR2 ways of how the code looks; but well that is how it is… After all it is just a code style - and I might get used to it :wink:

All the best,

1 Like

Excuse me, but are we switching from tabs to spaces with it too?

Code MUST use 4 spaces for indenting, not tabs.

All or nothing @dimaip, otherwise a standard makes no sense. As said I really dislike it, but tools will do the job. We can also decide to not switch. I just wanted to kickstart the discussion.

So @christianm, would you be up for creating a vote? I’d suggest to use a Doodle again to make things more transparent.

Here we go:

Thanks for starting the poll.
For those who are still not sure what exactly is different to our current CGL, there you go:

  • Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
  • PHP keywords MUST be in lower case. -> The PHP constants true, false, and null MUST be in lower case.
  • The opening brace for the class MUST go on its own line; the closing brace for the class MUST go on the next line after the body.
  • The opening brace MUST go on its own line, and the closing brace MUST go on the next line following the body.
  • When present, the static declaration MUST come after the visibility declaration.
  • Closures MUST be declared with a space after the function keyword


So there are no wide-spread alternatives to choose from? What @bwaidelich has summarized looks weird as hell.

What would be the advantage of the switch for the neos project? One could say that it makes it possible to get more external contributions if developers can stick to a style they are already familiar with but i do’nt think that this is a real problem now.

I’d suggest to only change things if there is a problem that is solved by the fix.

I think the biggest advantage would be that we are actually working in the same way as almost any other php community does which makes us a bit less “that closed group of people that think they have to do everything differently than the rest of the world” :wink:


The question here is not is it weird or not, it’s just about a standard widely used. And welcoming new contributors with “Please read our own CGL” is really weird. Dealing with multiple CGL is a fucking nightmare, especially for exotic CGL unsupported by your favorite IDE.

Yes brace placement look strange, but it’s just a brace placement nothing more :wink: I think having FALSE in uppercase it’s pretty weird in the current CGL :wink:

Anything that can ease the contribution is a good thing. As TYPO3 CMS is currently moving to PSR-2 if we stick with the TYPO3 CGL, we have to maintain the code sniffer and the CGL, it’s pretty a nice loose of man power.

Same things for the future JS CGL, use the Airbnb CGL or any other existant CGL is a good idea.

Let’s focus on the product and embrase more standard, and do less on our own side.


You get used to PSR-2 pretty fast :slight_smile:
Laravel changed lately to PSR-2 in their 5.1 release too!

There exists quite a neat tool to convert a php file to PSR-2. It’s called PHP-CS-Fixer
You would basically do

php-cs-fixer fix $file --level=psr2

I’m much in favor of a change :blush:
Standards are a good thing!

1 Like

I really hate PSR-2. I hope we don’t have to use it. Why do we have to adopt the crappy style that comes from Drupal and other ugly code bases? I would rather have a breath of fresh air in the Neos/Flow codebases before diving into the nastiness that is PSR-2 in 3rd party libs.

Yeah, I have no really good “arguments” against PSR-2 other than the emotional knee-jerk reaction to how ugly it is.

Must admit I’m sad that PSR-2 is becoming the norm and this is influencing our project, however I can see the benefit of adopting such a standard even though it has some things I really don’t agree to. In the past we decided not to adopt the PSR-2 since it’s purely aesthetics, hence has no influence on the function of the code and therefore not necessary to be compatible with other projects. The biggest benefit I see is the existing tools and not maintaining our own, although having to change every single line of code is not very cool :confused: Wish there was a better alternative tbh., but alas.