Earlier today, the PHP Framework Interoperability Group accepted two standards recommendations:
\nPSR-1, \u201cBasic Coding Standard\u201d, passed with 17 in favor and none against.
\nPSR-2, \u201cCoding Style Guide\u201d, passed with 13 in favor and 4 against, 1 abstaining.
\nThere\u2019s been a lot of commentary about these proposals over the past two weeks, some of it positive and some of it negative. Here\u2019s a taste:
\nhttp://forum.kohanaframework.org/discussion/10784/psr-1-and-psr-2/p1
\nhttp://phpmaster.com/psr-1-and-psr-2-to-be-approved-as-standards
\nhttp://blog.ircmaxell.com/2012/05/open-standards-better-way.html
\nI\u2019d like to address some of the negative commentary here; I don\u2019t expect to change many minds, but I do want to make sure the comments are answered.
\n(Full disclosure: I\u2019m a voting member in the group, and have been since its beginning. I did not introduce the original measure that led to PSR-1 and PSR-2; that honor belongs to Klaus Silveira, a non-voting member. However, I did shepherd the PSR-1 and PSR-2 recommendations through the voting process to their acceptance by the group.)
\nQ: What the hell is the \u201cPHP Standards\u201d group? I\u2019ve never heard of it before now.
\nThe name isn\u2019t \u201cPHP Standards\u201d any more; it\u2019s the \u201cFramework Interoperability Group\u201d (FIG). We did start off as \u201cPHP Standards\u201d because, well, we all worked in PHP, but realized pretty quickly that the name was too broad, and renamed it the \u201cFramework Interoperability Group.\u201d (That name turns out to be too narrow, as the group now has representatives from library and CMS projects as well.)
\nThe idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we\u2019re very aware that the rest of the PHP community is watching. If other folks want to adopt what we\u2019re doing, that\u2019s cool, but it\u2019s not what we\u2019re focused on.
\nQ: Then why is the mailing list called \u201cPHP Standards\u201d instead of \u201cFIG Whatever\u201d ?
\nThe Google Groups mailing list does still bear the original name of \u201cPHP Standards.\u201d It\u2019s a legacy issue. To reduce continued misconception, we need to change that to the reflect the new name, but I don\u2019t know when that will happen. (The Github repository for the group does use the new name.)
\nQ: Why are you guys so secretive and closed?
\nJust because you haven\u2019t heard of the list, doesn\u2019t mean we\u2019re keeping it a secret. There\u2019s a lot of discussion groups out there. ;-)
\nWe did start out with a closed list years ago, but we opened it up pretty quickly thereafter. Anyone can join in and make their voice heard.
\nThere\u2019s nothing \u201cclosed\u201d about the list or the decision-making process. Anyone who wants to drive the group to open even further is free to join the list and make suggestions for doing so. (I\u2019m looking at you Anthony Ferrara. ;-)
\nQ: So once I join the list, I can vote on PHP-FIG Standards Recommendations? Sweet!
\nSorry, no. The only people who can vote on a measure are the voting members. But anyone can discuss the measures on the list.
\nVoting is reserved for people who represent a member project. If you want to vote, then participate on the list for a while, and submit your project for membership. If enough other existing members vote in favor of your request, then you\u2019re in and can vote on measures thereafter.
\nQ: I knew it. You\u2019re a bunch of self-appointed elitist jerks.
\n\u201cSelf-appointed\u201d is probably accurate; \u201celitist jerks\u201d we can discuss. ;-)
\nRegardless, the group is currently composed of representatives who have volunteered from the following projects:
\nSome of these projects are large, and some are small (for various definitions of \u201clarge\u201d and \u201csmall\u201d). They\u2019re all very different from each other in lots of ways, and have very different ideas on how to approach various problems.
\nQ: Whatever. I don\u2019t need you guys telling me what to do. If I don\u2019t want to follow your so-called \u201cstandards\u201d then you can\u2019t make me.
\nWe\u2019re not trying to make anyone do anything. Hell, not even all of the member projects subscribe to all of the standards recommendations. What we\u2019re trying to do is find commonalities between the projects so that we (the members) can all eventually share similar practices and techniques.
\nQ: Who the hell are you to define a \u201cstandard\u201d for coding style?
\nIt bears repeating: the primary audience for the recommendations is the group itself. If others in the wider PHP community want to adopt the recommendations, I think that\u2019s a positive outcome, but it\u2019s certainly not mandatory in any way.
\nQ: Coding style is all personal preferences. How can you make a \u201cstandard\u201d out of them?
\nOn one hand, you\u2019re right: a style guide is a collection of preferences. On the other hand, it\u2019s not exactly personal when a lot of different projects run by a lot of different people indpendently arrive at a similar set of rules.
\nQ: How did you come up with this stupid \u201cstandard\u201d ?
\nSomebody on the list mentioned that it would be nice to have a single style guide for member projects, code in different projects would look similar. He included an initial set of guidelines. Several of the voting members agreed that it was a good idea, and we expanded on that initial set of rules.
\nAfter some back-and-forth, someone else brought up the idea of doing a survey among the member projects, to see exactly how many projects are following which points of style. We ended up with 22 projects in the survey. The results made it pretty clear what the majority of projects were using for their standards.
\nQ: Only 22 projects, out of the whole world of PHP code? That\u2019s not a valid sample size!
\nRecall that our primary audience is the group itself. If you have the time, energy, and inclination to do a survey of defined coding styles across the entire PHP community and analyze the results using a statistically valid methodology, I will be very interested to see your report on it.
\nQ: Where\u2019s this survey at? I bet you\u2019re hiding it so nobody can see the results.
\nHere is the original Google spreadsheet. It is also incorporated into the PSR-2 document as an appendix.
\nQ: Oh my God, you\u2019re saying we MUST use spaces and not tabs? But I hate spaces!
\nIf the majority of surveyed projects had used tabs, the recommendation would have been to use tabs. A super-majority (two to one!) use spaces, so that\u2019s the recommendation.
\nNeither tabs nor spaces has any moral superiority over the other. If you hate spaces so much that you simply cannot adjust to them, that\u2019s fine. Your project won\u2019t adhere to PSR-2, but then, nobody says you have to.
\nQ: Why can\u2019t the rule be \u201cuse either tabs or spaces, as long as you\u2019re consistent within a project?\u201d
\nThe focus of these recommendations is not \u201cindivudal projects by themselves.\u201d The focus is on \u201cworking with/on lots of different projects.\u201d If one project wants to use tabs, cool; if another wants to use spaces, fine; but if you end up working on both, you want the rules to be the same for each one. Thus, we have to pick something to apply identically across lots of projects at the same time.
\nQ: The standard is inconsistent: braces in one place sometimes, and in another place at other times. Dumb!
\nI\u2019ll refer you back to the survey; the brace rules are what the majority of member projects have already picked for themselves. (A minority of projects consistently put braces on the same line, and a different minority consistently put braces on the next line, but there was no majority that consistently put them in the same place.)
\nQ: Wait, you mean the rules are defined by a survey, and there\u2019s no design involved at all? Brain-dead!
\nThe \u201cdesign\u201d portion happened in the individual member projects. The survey identified common elements of design across those projects. The follow-up discussions refined the broad commonalities, and the proposal codified them.
\nQ: There are lots of other standards out there. Why not just pick one of those?
\nIn a way, we did, although in a very roundabout way. The survey revealed that the majority of member projects are already adhering to a large subset of the PEAR standard (itself the oldest existing common standard in PHP land.)
\nIf you have other questions or comments, please leave them below. I know this kind of topic inflames passion, so please, follow the example of the FIG members: be civil and constructive. I reserve the right to police comments according to my own whims. ;-)
\n" }