Don't follow PSR-2

[kelunik]

I hereby propose not to follow PSR-2 (completely). I'd like to have opening braces always on the same line, also for classes, methods and functions.

Already multiple people expressed they don't like that part of PSR-2. (That doesn't mean they expressed support for this proposal)

• bwoebi
• assertchris

[assertchris]

@kelunik please don't take my words out of context. While there are inconsistencies I don't personally agree with, I do think we should be following PSR-2 (read: please remove my name from the list of endorsements).

1. This group started out of a discussion in FIG, and unless our opinions have drastically changed, it's still a possibility that we will take the standards back to FIG to be voted on.
2. PSR's are the closest thing the community has to official standards.
3. It is 0 effort to follow PSR-2 (php-cs-fixer) and the style does not affect the efficacy of these async standards.

[kelunik]

@assertchris Read carefully, I didn't say you endorse it. I said you don't like that part of PSR-2.

it's still a possibility that we will take the standards back to FIG to be voted on.

Sure, it's a possibility. I still don't like it. I think async standards do not fit into the FIG. But that's another topic. We already don't follow FIG's bylaws.

PSR's are the closest thing the community has to official standards.

That may be true. But it's nothing the community decided. It was decided by major frameworks.

It is 0 effort to follow PSR-2

Following code styles isn't about effort.

[assertchris]

Read carefully, I didn't say you endorse it. I said you don't like that part of PSR-2.

On it's own, that is what you've said. However, given the framing of the discussion "Don't follow" and the positioning of our names alongside the leading "Already multiple people expressed"; it's easy to mistake dislike for one aspect of the PSR for agreement with the idea that we do should not follow PSRs.

Sure, it's a possibility. I still don't like it. I think async standards do not fit into the FIG

I agree with this. I think many of them are incompatible with async in how they define return types and ignore some basic things. I just don't want it to be an automatic decision. I'm glad you started the discussion here. Consider me arguing the other side so that the decision is better.

Following code styles isn't about effort.

Of course it is. Why pick a code style to begin with? Is it so that newcomers can integrate more easily? So that team members can discuss things without bothering to discuss small code style issues? So that our code can interoperate with code written by others [in the same style]?

All of those things are about effort. Without consideration for effort, the entire basis of a code style is personal preference. And I'd far rather side with a commonly accepted PHP open source "standard" than forge a new code style based purely on personal preference.

Still, it's not a decision up to me, but rather the whole group. This seems like the sort of thing (personal preference) that could only practically be settled with some sort of vote or deference to concerns other than personal preference...

Edit: I'm self-throttling now.

[AndrewCarterUK]

I'm a strong -1 here - I believe we should use PSR-2 in all of the projects that this organisation undertakes (including the event loop play ground, etc).

I also had preferences of coding style before PSR-2. However, these standards have provided immense value to me since then - as I have been able to contribute to a plethora of open source projects without glancing at another style guide. As the focus of this project is interoperability, I don't think we should disregard standards that give so much value to that cause without serious reason.

I also don't think this is about the FIG, even if the FIG disbanded tomorrow this standards would still be the most widely accepted PHP style guide.

[bwoebi]

I'm +0.5 here. While I dislike that particular part of PSR-2, I'm not sure whether we want to do that in an official repository. I like the fixed version, but it's more applicable for not-so-official repositories (i.e. everything but (de-facto) standards).

[sagebind]

PSR-2 isn't my personal favorite coding style either, to be honest. But all it is is personal preference, and I value using a standard coding style more than I value what my preference is. The point of PSR-2 (my interpretation on what it has become; it may not have been created with this intention) is to have a reasonable and common style guide for everyone to use so we can stop wasting time talking about code style.

• Adhering to a coding style guide within a project: Much value, improves consistency, readability, etc.
• Making your own style guide: A waste of time not spent on the actual design or code of a project, custom guide could be a gotcha for new contributors, etc.

My 0.00000002 million bucks.

[kelunik]

@coderstephen Sure, I agree. It's just that like every single person in here doesn't seem to like that part. Hence the issue, so we can discuss.

[trowski]

While I also personally prefer the same coding style as @kelunik, I'd rather stick with an accepted standard here, as I would hope many from the PHP community would use and contribute to this standard. Most in the PHP community expect to see PSR-2 style, so lets not surprise them or require that they read another style-guide.

[bwoebi]

Closing as we seem to have relatively broad agreement to not alter this.