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.
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?
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
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.
Yes - but it still looks ugly 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.
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”
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 I think having FALSE in uppercase it’s pretty weird in the current CGL
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.
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 Wish there was a better alternative tbh., but alas.