TravisSwicegood.com

2 June

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:

  1. Namespace usage and package/component naming structures
  2. Naming of classes, interfaces, and abstracts
  3. 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.

Tags: php, standards

9 comments

Giving up on open discussion due to noise feels unwise, and will likely decrease the acceptance of these standards. Guiding discussions is possible (an art), as described here:

- http://producingoss.com/en/communications.html
A standardization effort is definitely something that would be useful. Definitely something we from Midgard could be interested in joining!

Possibly also some configuration and deployment conventions could be discussed.

Regarding namespacing, here are the old Midgard namespacing guidelines:

http://www.midgard-project.org/documentation/concepts-midcom-specs-architecture-namespacing/
As I was there, I have already agreed to the proposed way, but I just want to offer an extra support by ways of this comment.

Philip Olson: The thing is that the standards as discussed right now are not necessarily required to be adopted by the masses. They are mostly meant for libraries and frameworks, to make it easier for the end user to combine the different libraries and frameworks in their projects without having the need for all kinds of loaders from different projects. As such, the main adoption needs to come from the framework leads and framework developers, and a good bunch of those were (represented) in the meeting. Leaders and/or developers of those that were not there are invited to join the discussion (as it concerns them). The only people that are "excluded" from the list are those that probably will never really need to implement the standards, but that will use the libraries who implement the standards. And yes, those are the masses, but since these standards hardly have any meaning for them, it will help keep the project productive by "blocking" those from entering the discussion.
Stefan: I'll instead refer to recent posts made by Rasmus and Greg on that list, which I feel addresses our thoughts. So, we agree to disagree, as it were.
"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."

And how does standardizing on whether interfaces are called iFoo or FooInterface do anything to make PHP code as a whole more maintainable in the eyes of other language communities? I assure you I can write absolutely horrific code that no one, not even I, could maintain no matter what naming convention you choose. :-)
@Larry: It's a perception thing. Right now it appears the community is doing nothing. My hope is that by starting this, we can move to some sort of standardization, at least across major frameworks and libraries, so there's at least a certain level that code is expected to be at when you're reading it. I'm not saying it's going to make it any better, I can think of some horribly written Python that's fully PEP-8 complainant, and still looks like crap. :-)
@Stefan I think that's a bit of a slippery slope. No one has to use any of the new features in PHP 5.3 and no one is forcing them to upgrade, so they fall under the "not necessarily required to be adopted by the masses" criteria as well. However, the internals list isn't moderated, when by your logic it should be.
"followed by pages of well meaning, but generally irrelevant content"

In essence you are saying that the group needs to be closed because the non-elite can't be trusted upon to have a reasonable discussion.

Maybe a solution would be to get a draft out from this closed group and open the process from there.
Coding standards are a good start, however it seems every project is reinventing the wheel every time someone has a need, and typically these are not interoperable.

I'd argue PHP needs something along the lines of the Java Community Process. I have seen mention of something like this, and some porting of JSR specs in PHP, but I don’t see anything established yet. There are far too many projects with basically identical goals that exist only because the initiators had divergent views on how to accomplish the task. There obviously needs to be more community governance that agrees on the goal, defines interfaces and any necessary implementation details and the projects can go to town with different ways of implementing them as necessary. The benefit to the community would be an easier time swapping in and out projects. That or even having the option.

Ditto @Koen, it should be an open process at some point.

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)