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?
Jettison the PEAR coding standards
Jettison the PEAR coding standards
Christoph M. Becker – Plugins for CMSimple_XH
Re: Jettison the PEAR coding standards
Well, so I propose to switch to the PSR-2 coding standard (which extends PSR-1) with a minor modification regarding autoloading, namely that
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.
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.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.
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