My goals for the PHP standards group

A few weeks ago at php|tek, I corralled developers from all of the major PHP frameworks into one of the conferences rooms. The idea was simple: in the PEAR Group we've been discussing our new PEAR2 Coding Standard and have come to some conclusions on how PHP 5.3 code should be handled moving forward. A standard is only a standard if people use it, though, and PEAR is not entirely representative of the community at large.

That's where this group comes in. By having official representatives from PEAR, Agavi, Cake, Solar, and Zend Framework and unofficial representation from Phing and Symfony, we had a good cross section. I went into the meeting with 3 items I wanted to pick off, which were, in order:

Namespace usage and package/component naming structures
Naming of classes, interfaces, and abstracts
Naming standards for Exceptions

I had hoped that we'd make it through the first one, but fully anticipated it taking longer. About 20 minutes into the meeting, we were already moving on to the second item! We flew through the list and were all extremely energized by our productivity. We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects.

We also decided to setup a mailing list. Given all of our experience with the proletariat, we decided to make the list moderated. This has proven to be the biggest flash-point so far, drawing criticism from the creator of PHP, himself.

For better, or worst, I stand by my decision to vote for a moderated list. Below is what my vision is. It's my vision and mine alone, but this is where I'm coming from. I posted it earlier this morning to the internal list that we've started to discuss moving these standards forward.

I'd love to see an officially sanctioned standard come out of our work. All of us are too busy, both with real jobs and our various projects, to fight the battles that come of trying to make this a completely open process where anyone with an email address can contribute. Sad as it may be, pear-dev has demonstrated that coding standards *must* go the way of sausages and laws lest they devolve into a constant "but I think <insert favorite coding standard pet peeve> is better, and this is why..." followed by pages of well meaning, but generally irrelevant content.

My reason for wanting a standard is simple, I move among other coding communities in addition to PHP and I am constantly put in a position that I must defend PHP against criticisms that it is unmaintainable, barely useable, and only useful if the least common denominator is your sole concern. Needless to say, I think those are opinions are misguided at best, and patently wrong at worst; but then someone looks at WordPress or phpBB or <insert favorite "I'm amazed it actually runs" project written in PHP> source code and has all their criticisms validated.

As a community, we need to be able to come together and agree on a coding standard. When code is published for public consumption in a year, I would love it if the first comment on blog posts or mailing list messages announcing the new code is "wow, that's great, but you should run it through phpcs." In Python it's not uncommon for pastebin'd code or newly published code to have a response "read pep 8." They aren't trying to be mean or petty, they're just trying to guide someone down the path to good citizenship in the Python community.

Given it's frigid—even hostile in some cases—reception, it does look like having an official coding standard for frameworks and libraries is our best outcome. Hopefully, with the projects in the community we have behind this we'll be able to build up a consensus and prove our decisions the correct ones. If not, then at least we've expanded the number of projects we can easy move between out from our small enclaves to a wider swath of the PHP landscape.