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!
Post Reply
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Jettison the PEAR coding standards

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

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Jettison the PEAR coding standards

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

Post Reply