In this latest post to his site Chris Hartjes shares some of his thoughts about the recently approved PSR-3 standard (for logging) and some of the reception that the other PSRs (PSR-0, 1 & 2) have gotten from the PHP community.

For those who pay attention to the workings of the PHP community you might have heard about the "PHP Standards Recommendations" that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other's libraries of code together [by standardizing their formatting] is asking for irrelevancy.

In his most recent post Matthew Weier O'Phinney (lead on the Zend Framework project) takes a look at the PHP Interoperability Group (php-fig) and some recent discussions that have come up about shared interfaces for things like logging and caching.

A little over a year ago, there was a new push by a number of folks wanting to do more. Paul Jones did a remarkable job of spearheading the next two standards, which centered around coding style. [...] And this is when we started seeing proposals surface for shared interfaces, first around caching, and now around logging (though the latter is the first up for vote).

He talks a bit about shared interfaces - what they are and what kind of problem they aim to solve - and how he's not sure he "buys into them". He notes that "sharing is good, developing solutions is better" and stresses making it easier to operate with each other and not worry so much about standardized interfaces.

He's found a few problems with the concepts behind them like the Not Invented Here (NIH) idea they promote and that there's not really just a single solution to these kinds of problems ("space for multiple implementations"). He suggests an alternative to the idea of these shared interfaces - bridges/adapters. He illustrates this idea with some code showing the implementation of a "CacheInterface" and a "FrameworkACache" adapter that wraps the functionality of a "CacheItem" class that might be internal to your application already.

In a recent (controversial) post Richard Roger talks about why he's given up on coding standards and includes a few of the reasons that might make you think about your own proceses.

Every developer knows you should have a one, exact, coding standard in your company. Every developer also knows you have to fight to get your rules into the company standard. Every developer secretly despairs when starting a new job, afraid of the crazy coding standard some power-mad architect has dictated. It's better to throw coding standards out and allow free expression. The small win you get from increased conformity does not move the needle. Coding standards are technical ass-covering.

He walks through the evolution of the average developer, the trip from their infancy of "just writing code" to the point of understanding that there needs to be standards to make code easier to read and understand. He includes a list of five "sins of control" that might make coding standards more desirable.

There are worse sins than these. You only need one of them to end up with a coding standard. The truly evil thing about coding standards is what they do to your heart, your team's heart. They are a little message that you are not good enough. You cannot quite be trusted. Without adult supervision, you'll mess up.

As you'd expect, there's plenty of comments on the post, so enjoy reading and maybe contribute some of your own.

To help resolve issues that have come up around its formation and to keep too much FUD (fear, uncertainty and doubt) from spreading, the "PHP-FIG" (framework interoperability group) has put together a site and a FAQ describing what they're all about.

The FIG stands for Framework Interoperability Group. The name until recently was "PHP Standards Group" but this was somewhat inaccurate of the intentions of the group. [...] The 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're very aware that the rest of the PHP community is watching.

The FAQ answers other questions about the standards the group has agreed on (passed) so far, who the members of the group are, how to get involved and how framework communities can get involved.

In the Kohana framework, you can get an inside look at the discussion inside a framework community regarding their adherence to the PSR-1 & PSR-2 standards (hint: they're not in favor).

A commentor asks the question "Will Kohana eventually follow the following guidelines?" and is immediately given the simple response of "no". Other comments reinforce this by pointing out some of the differences in the standards that the framwork follows and what the PSR standards outline.

Other posters make comments about the PHP-FIG group themselves, some of the things outlined in the standards and some of their own personal preferences when it comes to the the standards of their own code. You can find more information on the standards here: PSR-1 and PSR-2.

The PHPClasses.org site has released the latest episode in their "Lately in PHP" podcast series - Episode 24, "Do PHP Developers Need and will Adopt PHP Coding Standards?"

The PHP Standards Group is trying to push new specifications for PHP coding standards. Whether PHP developers need and will adopt these standards was one of the main topics discussed by Manuel Lemos and Arturs Sosins in episode 24 of the Lately in PHP podcast.

They also talk about some of the comments that Linus Torvalds recently made about the limitations of Github and recent PHP releases (bugfixes). You can listen to this latest episode using the in-page player or you can download the mp3 and listen locally. If you enjoy it, consider subscribing to their feed to get this and future episodes.

In a new post to his blog Pádraic Brady gives his take on the PHP-FIG (Framework Interoperability Group) and some of the decisions they've been making on PHP coding standards.

Anthony, whose views always make good reading, raises concerns about the way in which this group generates standards. He contrasts the current approach to RFC 2026 which defines the IETF's Internet Standards Process. [...] Where Anthony's arguments seemingly fall flat is that the FIG is not the IETF. The Framework Interoperability Group was founded to allow cooperating members to develop shared standards. It does not claim to be PHP's standards body and so there is no obligation for any PHP programmer to adopt their standards (unless they work on a member project obviously!).

He points out that the standards group's process has been slowly opening more and more ("by inches") and that the group, while made of up individuals, is more than just a collection of people - it's representatives for well-known Open Source projects.

In other words, the FIG is actually something really really good for PHP. PHP needs standards so we can make interoperability between various frameworks and applications a true reality. The hodgepodge of APIs and standards we've relied on to this point only serve to reinforce PHP's NIH obsession. [...] What the FIG should do, in my opinion, is clearly define its purpose and better document its bylaws/processes. [...] It really all comes down to better communication and pushing the community engage with the FIG.

Brian Moon has shared some of his thoughts about the recently proposed standards (PSRs) from the PHP-FIG group based on some discussions had at this year's php|tek.

During the /dev/hell podcast at Tek12, someone asked the guys their opinion about PSR. [...] The person asking the question had asked about PSR1 and PSR2. These are the first two standards proposals in the group and they deal with coding standards. [...] There are already coding standards for PHP and any other language out there. Why does anyone need to make a new one? [...] This reminds me a lot of Open Source licenses. There are tons of these things. And in the end, most (GPL has its issues I know) of the open source licenses represent the same idea.

He goes on to talk more about the feedback he's gotten from other PHP community members about the target of the group and his thoughts on the naming of both the group and the standards they're generating.

In the end, cooperation is good. And if these guys want to cooperate I say more power to them. I just hope they get into really good things soon. Like, can we talk about a maximum number of files, functions or classes used for any one single page execution? *That* would be valuable to the PHP community.

In this new post to his blog Anthony Ferrara responds to some of the recent news about PHP standards being up for voting (PSR-1 and PSR-2). He has an issue with how they were created, though, and notes that the current PSR process doesn't encourage open standards.

There has been a lot of traction lately on the topic of the PSR "PHP Framework Interoperability Group". They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. [...] I have read both, and actually agree and think they are quite good. However, there's a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

He describes an "open standard" and points to this RFC as an example of the open process they should result from. He talks about the importance of the process and how having more people reviewing and contributing their ideas could help find issues in the proposal. He issues a "call to the PSR team" to adopt this practice, allowing a more open flow to the ideas that are being proposed.

Note that I'm not asking to open the vote to anyone else. I'm not saying that standards should be approved by everyone in the community. There should still be a standards body that makes the final decision. But they should make that decision based on community input. They should actively look for and encourage open discussion prior to voting.

On the Voices of the ElePHPant podcast, the latest episode has been released - FIG, PUD & FOMO, a discussion with members of the PHP Standards Group: Matthew Weier O'Phinney, Jeremy Lindblom and Paul Jones.

Cal's questions center around the Standards group and what kinds of discussions they have about the language and the progress the group has made so far (like PSR-0):

• What's the purpose of the group?
• Is the purpose of this group to take PHP from everyone's hands and enforce the "one true grace" on everyone?
• Is the group fulfilling its purpose or is it wandering off the path?

You can listen to this latest episode either via the in-page player, by downloading the mp3 or subscribing to their feed.