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

"G. P. B." <[email protected]>
Newsgroups gmane.comp.php.documentation.general
Message-ID <CAFPFaMJgNLhUG2+Qwk+OaNbGT5gQHw1ySkxqtc-ZoTxU5NZs_Q@mail.gmail.com>
On Fri, 4 Sep 2020 at 16:49, Tymoteusz Motylewski <[email protected]>
wrote:

> 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
>
> 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:
> - 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
>
> > "If PHP were to follow their guidelines then that could be interpreted
> as an endorsement "
>
> 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 ;)
>

The PHP documentation doesn't endorse any coding style as the examples
aren't very consistent, and I'd argue most of the examples follow PSR-2
more or less.
For the sake of argument, let's say PSR-2 is the current official
coding-standard, should we still "upgrade" to PSR-12 although it is
incompatible with PSR-2?
If so, which tooling is available or need to be created such that:
 - Coding style is enforced
 - Automatic fixes, or pre-commit hooks which denies the commit
Which works on the current PHP Documentation infrastructure (SVN) and can
deal with Docbooks the format in which the PHP doc is written.

Moreover, those rather superficial changes put a lot of strain on
translations because now a bunch of legit pages which need to be updated
are buried under the tons of pages which need coding style updates. And
automatic fixes and revision updates for translations is not something
doable in the current state of affairs.

And what happens if the FIG implodes on itself and another body creates a
new coding style taking into account features which might only exist 5
years from now? Should we then change again?


> 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
>

PSRs are something completely independent from PHP, sure it is ubiquitous
but one could have said the same about PSR-0 before.
Therefore "trends" (using this word for lack of something better I can
think of) shouldn't be mentioned in the documentation IMHO.
Otherwise one can say we should mention frameworks such as Symfony, Laminas
(previous Zend), Yii, Laravel, etc.


> 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 documentation is a language reference and extension reference akin
to how Python does it (to name one example).
The PHP documentation has already a tutorial but it might be severely out
of date, see: https://www.php.net/manual/en/tutorial.php


> I would like to hear your opinion about this topic.
> Thanks
> Tymoteusz
>

As currently presented, it seems that your complaint is about the wording
on one page meant to help people contribute to the PHP documentation.
And as such I find this proposal lacking any substance.

Best regards

George P. Banyard
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.