Jettison the PEAR coding standards

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
cmb
Posts: 11577
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Jettison the PEAR coding standards

Postby cmb » Wed Dec 07, 2016 11:04 pm

Hi!

Some years ago we agreed that CMSimple_XH should adhere to the PEAR coding standards. This was a reasonable choice back then, especially as we had to support PHP 4, but XH 1.7 is supposed to support PHP 5.3+ only, and uses namespaces, which are not really supported by the PEAR CS. And, after all, the PEAR CS appear to be dead.

Therefore I suggest to switch to some more contempory coding standards. PSR-2 comes to mind, but maybe there are better alternatives. Any suggestions?
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+

cmb
Posts: 11577
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Jettison the PEAR coding standards

Postby cmb » Sat Mar 25, 2017 1:43 pm

Well, so I propose to switch to the PSR-2 coding standard (which extends PSR-1) with a minor modification regarding autoloading, namely that
This means each class is in a file by itself, and is in a namespace of at least one level: a top-level vendor name.
A vendor name doesn't fit well to CMSimple_XH's plugin system, so I suggest to use the plugin name instead of the vendor name. That conforms to current master where XH_autoload() and plugins using classes (filebrowser, pagemanager and tinymce4) already follow this convention.

I also propose to stick with PHP CodeSniffer to check for CS violations (from my experience it works fine with PSR2).

Finally, I propose to fix all CS errors reported by the adapted phing `sniff` target, and maybe some of the warnings. Also some refactoring with regard to the line-length (which may exceed 80 characters according to PSR-2) would be reasonable. Furthermore, the protected properties and methods should be made private (unless they need to be protected); we had used protected properties and methods in many places only to get around the PEAR CS enforcement of ugly and inflexible underscore prefixes for privates. The doc-block comments should stay as they are for now (even though they're often utterly verbose).

I don't think that creating a PR upfront would be reasonable, because (a) it's pretty was has to be changed if this proposal will be accepted, and (b) a respective PR will most likely cause to many merge conflicts.
Christoph M. Becker –Plugins for CMSimple_XH, but not for CMSimple 4+


Return to “Open Development”

Who is online

Users browsing this forum: No registered users and 1 guest