[wp-trac] [WordPress Trac] #23357: PSR compatibility

[WordPress Trac]

#23357: PSR compatibility
-------------------------+------------------------------
 Reporter:  fale         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  close        |
-------------------------+------------------------------

Comment (by nacin):

 PSR-0: If/when we move toward SPL autoloading (which does not benefit us
 much right now, given WordPress is relatively small, procedural, and
 tightly-coupled), there is not a doubt in my mind that we would look at
 PSR-0 when doing so. Given that two-thirds of all WordPress sites run PHP
 5.2 still, namespaces are not something I am wasting my time on
 considering how or if we will implement them.

 PSR-1: Some of this is already applicable. We only use `<?php` and have no
 plans for `<?=`, because it can get turned off with short tags on servers
 until 5.4 (1% of all WordPress sites). We use only UTF-8 and avoid BOM.
 rmccue expressed difficulty in the side-effect guideline, but this is
 something we actually just naturally strive for anyway. (Moving a bunch of
 add_action() calls into default-filters.php isn't a big deal.) But, our
 coding style is underscores. We're never going to use StudlyCaps or
 camelCase. Like a number of FIG projects, there are simply going to be
 some coding and interoperability standards that we will ignore.

 PSR-2: Most of this goes against our style guide and is not something we
 will adopt. Opening braces do not go on their own line. Tabs, not spaces,
 for indentation. We use spaces liberally, for function calls, control
 structures, and such.

 PSR-3: Not applicable, as rmccue stated.

 Some changes would significantly alter the shape of WordPress's codebase,
 and that's not something we care to do. Not just that, but many of these
 changes — including something as simple as StudlyCaps and camelCase —
 would be a backwards compatibility nightmare. '''We do not break
 userspace.''' When we do so (which, despite not having "breaking"
 versions, we do so rarely), we better have a damn good reason, and the
 PSRs aren't even close to it.

 For the version number X.Y.Z, major is X.Y, while minor is Z. There is no
 difference between 3.9 and 4.0 and 4.1 — all are major versions.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23357#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software