Plugin-php: PSR discussion

[alexander-akait]

I think we should right now resolve this issue, at the moment we are trying to adapt PSR-2, but personally I think this is not quite the right direction. A lot of projects do not fully respect the PSR-(1/2/12) or use its modifications. Other PSR standards may also appear in the future, and they may not be compatible with old PSR. My idea is:

1. The starting configuration does not contain any PSR value, it just makes a beautiful output.
2. We add the option --psr=1, --psr=2, --psr=12 and maybe other value in future.

This will allow projects to migrate easier to the prettier and simplify maintenance. Also use prettier for projects that do not use PSR

/cc @vjeux

[vjeux]

My recommendation would be to aim at printing a single style as good as possible. Try to use your best judgement to follow common usage and with the constraints of an automatic one.

Once you have it working and a ton of people are using it, then you can worry about tweaking the rules.

Those recommended style guides are super important when you are formatting your code manually, but when you have a tool to do it, they don’t really matter anymore. The only cost is when you convert your codebase to prettier the first time, you’re going to see the difference.

In my experience, php is the wild west like JavaScript and those official guidelines are weakly enforced at best. So I wouldn’t put too much emphasis on them in the early stages of the project.

[alexander-akait]

@vjeux agree, initially it would be worth stabilizing the output, without PSR compat.

[alexander-akait]

/cc @czosel @mgrip

[czosel]

I agree we should focus on a single style for now. The bigest value i see in adopting the PSR-(1/2/12) style is that we don't have to have lengthy discussions about every single stylistic decision. If someone can suggest a styleguide that is relatively complete and more popular within the community (maybe something from laravel?), I'd be happy to implement that instead. The only thing i'd like to avoid is the lengthy discussions :wink:
@vjeux How were those decisions made for the JS printer? It doesn't implement a specific styleguide, right?
/cc @mgrip

[alexander-akait]

@czosel Some PSR improvement seems should be basic (example hardline after namespaces and hardline after use group, because it is have pretty view)

[czosel]

Yes, but are we also talking about some "PSR improvements" that are in conflict with an actual PSR?
Maybe it would help if you could post some "improved" styleguides that we should have a look at?

[alexander-akait]

@czosel right now no, but i think it can be, let's left issue open for discussion and feedback

[vjeux]

For prettier, I used a combination of my experience writing JavaScript for 10+ years, grepping through the millions of lines of the Facebook codebase to see which style was more popular, reading through various coding styles (eg Airbnb) and what are all the related eslint configs and finally feedback from people complaining that some pattern looked bad.

My guiding principle was for the code generated by prettier to pass code review as if it was written by a human. I also tried to make all the decisions be as less controversial as possible.

[vjeux]

Also, one thing that really helped is to have someone to make the final decision. This way all the discussions could happen and were useful input but at the end of the day, only the things I wanted would go through.

I found that there are a handful of useful tactics to manage those discussions:

• Ask for specific snippets of code and try to find solutions for those. So many times people argue about very general things but in practice there are concrete fixes you can do for their use case.
• Explicitly say that you're not going to make a decision right now on certain issues. One thing that people pick up quickly is to engage in places where the people involve the project are responding. Then once in a while you can sort issues by upvote/comments and figure out what are the most painful things and do a deep dive.
• Avoid style trashing. Ideally, you should think deeply about each important style decision you are making and once you do it, actually commit to it. This way you can "close" the issue and whenever this subject comes up in the future say that you have reached a decision and are not looking to spend time thinking about it for now. This way you can focus on the things that still need to be fixed rather than going through the same discussions over an over again wasting everyone's time. This is hard to do in practice but if you can pull it off, it'll help a lot.

[mgrip]

All of this is great advice - thanks @vjeux! I agree w/ @czosel that I think the real value of having a standard to point to (at least for now) is that we can push through to get a working v1 without having to spend time discussing formatting opinions. I think this blog post does a fairly good job of summing up the state of php formatting standards - although its definitely still a bit of a wild west, there are several popular coding standards that have emerged and are used in large, widely-known open source projects - these are PSR1/2/12, PEAR, and Symfony, which are all actually fairly similar. Indeed existing linters like PHP_Codesniffer and PHP Coding Standards Fixer typically default to one of these formatting styles.

Definitely agree that at some point we should spend some more time thinking critically about some of these stylistic decisions, but in my opinion at this point it would be valuable to have one accepted (and well documented - PSR2, PEAR) standard we can reference to help us move quickly towards a first iteration of a fully-working product.

[alexander-akait]

@mgrip for other stylistics we can documentation bunch (example prettier + PHP_CodeSniffer)

[alexander-akait]

@vjeux I apologize, can you invite me in repo?

[vjeux]

Made you all three admins of the repo.

[QWp6t]

If someone can suggest a styleguide that is relatively complete and more popular within the community (maybe something from laravel?)

I don't think you're going to find a PHP styleguide more widely adopted than PSR-2. (Laravel uses PSR-2)

Yes, but are we also talking about some "PSR improvements" that are in conflict with an actual PSR? Maybe it would help if you could post some "improved" styleguides that we should have a look at?

That's exactly what Symfony does. Symfony is PSR-2 compliant but then extends it with their own rules for situations unaccounted in PSR-2.

[alexander-akait]

In PSR-2 we have:

There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

Should we change printWidth: 120 or not?

/cc @vjeux

[vjeux]

The way prettier algorithm works is by trying to cram as much as possible before the limit and only then to break. So if you put 120, most lines are going to be at 120. So this is not what you want to follow their description of PSR-2. You want 80.

[MichaelDeBoey]

The mostly used standard (right now) is PSR-2.
But since it doesn't cover all new PHP syntax, PSR-12 is going to replace PSR-2.

I suggest we should stick 100% to PSR-2 and try to look at PSR-12 when something isn't covered by PSR-2, since PSR-12 will become the new widely adopted standard when it's accepted. 🙂

[alexander-akait]

@MichaelDeBoey in some places we already support PSR-12

[MichaelDeBoey]

@evilebottnawi Like I said: if it's not covered by PSR-2, defo look at PSR-12
If PSR-12 has a slightly different implementation I think we should stick to PSR-2 (for now)

[mgrip]

I think we've aligned around PSR2 💯 Closing this out for now, if anyone disagrees feel free to re-open!