Change to PSR-2?

christianm · July 26, 2015, 2:46pm

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:

github.com

php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

# Coding Style Guide

This guide extends and expands on [PSR-1], the basic coding standard.

The intent of this guide is to reduce cognitive friction when scanning code
from different authors. It does so by enumerating a shared set of rules and
expectations about how to format PHP code.

The style rules herein are derived from commonalities among the various member
projects. When various authors collaborate across multiple projects, it helps
to have one set of guidelines to be used among all those projects. Thus, the
benefit of this guide is not in the rules themselves, but in the sharing of
those rules.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC 2119].

[RFC 2119]: http://www.ietf.org/rfc/rfc2119.txt
[PSR-0]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

This file has been truncated. show original

michael.gerdemann · July 27, 2015, 6:15am

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?

bwaidelich · July 27, 2015, 9:18am

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!

christopher · July 27, 2015, 12:53pm

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.

bwaidelich · July 27, 2015, 2:00pm

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

christianm · July 27, 2015, 3:31pm

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

christopher · July 27, 2015, 5:31pm

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.

sebastian · July 29, 2015, 5:42pm

Hey,

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

All the best,
Sebastian

dimaip · July 29, 2015, 9:39pm

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

Code MUST use 4 spaces for indenting, not tabs.

christianm · July 30, 2015, 8:29am

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.

christopher · July 30, 2015, 1:18pm

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

christianm · July 30, 2015, 3:16pm

Here we go: http://doodle.com/3xq2uvn4sa4d6tqu

bwaidelich · July 30, 2015, 3:48pm

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

GENERAL:
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.
CLASSES:
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.
METHODS:
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:
Closures MUST be declared with a space after the function keyword

E&OE

dimaip · July 30, 2015, 5:18pm

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

mficzel · July 31, 2015, 6:38am

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.

radmiraal · July 31, 2015, 10:32am

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”

dfeyer · August 2, 2015, 12:49pm

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.

davidspiess · August 2, 2015, 6:13pm

You get used to PSR-2 pretty fast
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
Standards are a good thing!

cognifloyd · August 4, 2015, 1:02am

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.

aertmann · August 4, 2015, 12:26pm

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.