Re: Use PSR coding guidelines in php.net docs (instead of PEAR-CS)

Kalle Sommer Nielsen <[email protected]>
Newsgroups gmane.comp.php.documentation.general
Message-ID <CAJW__o0yHKyWCsXDiSs7OUOiFeNcn83BnHjCN91iySmhAtUXtQ@mail.gmail.com>
Hi

Den fre. 4. sep. 2020 kl. 17.49 skrev Tymoteusz Motylewski
<[email protected]>:
>
> Hi,
> Right now (as stated here: http://doc.php.net/tutorial/style.php) the code style used in PHP documentation is PEAR-CS https://pear.php.net/manual/en/coding-standards.php
>
> The problem is that:
> - PEAR-CS does not cover new PHP versions (e.g. namespaces are missing)
> - it has a very little adoption
> - it's not maintained
> - the whole PEAR is becoming obsolete

See my inline reply further down. TL;DR the PHP Documentation Team
builds upon the old PEAR-CS, but there is nothing formal written down.

> I suggest that PSR-12 should become the coding standard for PHP docs.
>
> I've created a ticket https://bugs.php.net/bug.php?id=80060
> and got redirected to mailing list
>
> "The PSRs are unofficial community-written guidelines for interoperability between frameworks and projects. If PHP were to follow their guidelines then that could be interpreted as an endorsement - reasoning that extends to other areas, such as why php.net does not employ a popular framework."
>
> I would understand the concern if we were talking about certain commercial product, tool or framework.
> Here we're talking about a standard which:

That standard is however, still a tool.

> - has a broad acceptance in the PHP industry
> - doesn't have an alternative thus became the one standard in the industry
> - its adopted by many tools and framework from the PHP community

While these are solid arguments in their own right, it doesn't
necessarily mean that these merits also apply to the PHP project. Like
mentioned in the bug report, the PHP project must remain neutral. The
moment we adopt the X standard, then it will be seen as favoritism,
"Why does the PHP project use this standard when Y is clearly better?
I better bring my case up for using Y over X". If the PHP project were
to pick X coding standard then possibility for any widespread adoption
for anything else is next to nothing. Userland is free to create
whatever organizations you would wish to and support their course, or
not, in the same way that the PHP project strives to be neutral.

> I agree, and I would love PHP to either set standards, or to endorse existing standards. Because right now you can read this argument that PHP is endorsing obsolete PEAR-CS, which I hope is not true ;)

I think while we base the idea on PEAR, I think the style has slowly
evolved into our own with roots there of. I'm sure some examples out
there in the manual may be compatible with X, Y or Z PHP coding
standards, sometimes not. It is not really the end of the world if
some examples use K&R / Allman indentation style and others use OTBS.

The moment we however open up and decide to invent a new coding
standard, it will have many challenges, such as:
 - Everyone would want to take apart of it, because it is the PHP
project and there seems to be a certain prestige in having had a say
in something that involves the PHP project
 - There is the chance that someone will adapt that and what do we do
then, maintain it or? What if someone forks it and it becomes
widespread, do we then adopt that and break that neutral stance?

The thought of the political process of tabs v spaces, which
indentation style, and naming, would have to be redone. While I don't
speak for everyone, I can't stay that I know of anyone that would be
interested in such, nor do we have the infrastructure for something
like that to happen.

We even have a CODING_STANDARDS.md file in php-src, which is not
respected to the slightest, perhaps because it has not been updated
our "recent" switch to C99, but it is very common to have commits
break the C++ comment style rule for one.

> In general I would like to see more PSR being mentioned in PHP docs, e.g. PSR-4 in https://www.php.net/manual/en/language.oop5.autoload.php

We cannot do this because it creates favoritism, the moment we endorse
X, then Y wants some too and Z, and it will continue like that. That
is why it is very important for the PHP.net project to remain neutral.

> In comparison to other languages it's hard to learn PHP from the official docs, as no tooling or best practices are outlined e.g. I did not find any mention of composer in the docs.

The PHP manual is primarily a reference guide, it is not written as a
tutorial. There was a point some 10+ years ago where it was proposed
but it never manifested, and to be fair. At this point there are so
many other resources on the web which come and go all the time, if we
were to link to some, then again it creates a favoritism and it will
also become a maintenance burden as the links might change. We are
already fairly bad at the latter part.

-- 
regards,

Kalle Sommer Nielsen
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.