#php-fig

tl;dr: TYPO3 goes PSR-2

On the TYPO3 active contributors meeting we decided to change our coding guidelines and base them on the PSR-2 standard.

Though some developers have walked away and aren't looking back, the last years have seen changes in the PHP world that make it a more pleasant place to be.

composer / phar

Hack/HipHop VM

PHP-FIG (standards ftw)

phpng (PHP6)

After reading Matthew Weier O'Phinney's announcement that he's resigned from the PHP-FIG group, I thought I might share my thoughts on the PHP Framework Interop Group's direction and challenges, and where the Elefant CMS stands on the various PSRs.

First, I should state that I'm not a member of PHP-FIG. I applied to be a member representing the Elefant project, but saw projects with similarly-sized communities rejected, so I wasn't surprised at the lack of response to my application.

However, I do agree with the general goals of the project and think it has a lot of potential if steered well. I also follow the mailing list, although only as a lurker. Unfortunately, I also don't think there's much room to adopt their PSRs in Elefant. Here's a breakdown of where we sit with each standard (you can skip past the next two sections if you want to keep on the topic of PHP-FIG itself):

PSR-0

We implement namespacing based on app names in Elefant, so PSR-0 doesn't make sense for classes defined in separate apps. We also don't namespace our core classes because there are so few of them, and it leads to so much extra verbosity. However we do have strong Composer support, and our autoloader is PSR-0 compliant, so you can still use any 3rd party libraries within Elefant with no problems.

The lack of namespacing in our core classes is something Elefant has received criticism over. However, I see projects like Laravel doing the same thing in practice (aliasing a namespaced class into the global namespace by default is the same as just declaring it in the global namespace, regardless of how you organize your code behind the scenes), and it proves quite effective at creating highly readable, concise, almost declarative code. So I'm willing to take the criticism along with the benefits gained.

PSR-1 & PSR-2

With Elefant, I chose to use method names with under_scores instead of camelCase. I find they substantially improve readability, and while PHP moves ever-closer to Java in its syntax, I strongly prefer the direction Python, Ruby, et al take, and find underscores better match PHP too because every function in PHP uses them. So at this point I'm not renaming everything, or worse, using aliases so both ways can be supported. Instead I'm opting out of PSR-1.

I'm also firmly planted in the tabs camp for my own projects, which automatically precludes us from being PSR-2 compliant. However, I don't care whether you use spaces in yours. I just don't think this belongs in the standard, and so I'm opting out here too. I also find putting opening braces on their own lines, well, a bit abrasive :P

I should note that Analog, Elefant's bundled logging library, supports PSR-3. Remember, these are recommendations, and you can cherry pick the ones you feel work for you.

PHP-FIG's PR challenges

I think much of PHP-FIG's public relations challenges stem from what people feel is over-reaching in the standards. Case in point, the neverending debate about tabs vs spaces. The reality is that a sufficient percentage of the PHP community use tabs, and you can't exclude them or force them to your way of doing things without causing disagreement and disillusionment. Being absolutist on a matter of opinion like this one simply doesn't work with a community of this size.

But another issue the group is having is that there are now sides forming in the conflict between the external community and the PHP-FIG members, and PHP-FIG members don't seem to recognize the greater community's complaints as valid, as evidenced by threads like this one from their mailing list.

In the first message, Paul Jones calls the community a "mob crying for tabs", while subsequent responses essentially high-five him on the ad hominem attack. This attitude from within the PHP-FIG membership will be the very thing that destroys it, unless that changes fast.

PHP-FIG has grown rapidly since its inception, and with that comes the need to reevaluate and adapt. The PHP community is huge, and a group hoping to represent even a substantial minority of it will have to practice diplomacy and clearly state its intentions if it doesn't want to be misunderstood or cause alienation amongst the wider community.