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.

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.

As a long-time programmer, often with a staff of other programmers to watch over, I learned early in my career how important enforcing programming standards is in contributing to the overall success of a project. Not only do standards affect an individual's production of code, but they ensure that anyone else who may contribute code later can do so with a reasonable expectation of consistency.

He defines the abstract concept of "coding standards" as rules or guidelines that should be followed based on the application. Sure, there's more global standards for things (PSR-0 anyone?) but your needs will always be different and more fine-grained than those can get. He recommends standardizing everything, possibly using one of the standards popular open source projects have already laid out as a base.

PHP_CodeSniffer is probably the most convenient tool out there to analyze your source code and to verify it complies to company policies. Although it's debatable why source code should follow strict guidelines, it's only a matter of time before you discover yourself that it pays off to have a code base that appears to be written by one developer.

He talks about how it works to keep every brace in the right place and format the same through out all of your files. He also mentions that its standards are flexible and can be modified as you might see fit. He looks at the installation process (both manual and through the PEAR installer) and how to use it to analyze your codebase. He's even included a short screencast in the post so you can see the results first-hand.

The phrase "spaghetti code" is an all-too-common pejorative we programmers use to describe horrible code, whether it's difficult to understand, poorly organized, or just plain long-winded. And there-in lays the problem. What really constitutes spaghetti code is subjective; I've yet to hear a concrete definition or standard metric that measures it. [...] Everyone has his or her own opinion as to what aspects would make them label it spaghetti.

Suggested definitions include: quickly written, non-standardized, beginner-level quality and any code that makes use of "goto". He suggests that applying the term to someone's code is less about the real quality of the code and more about social aspects of not wanting to upset the other developer over its quality.

But besides negatively affecting others, our complaining about spaghetti code hurts ourselves too. It's easier to motivate ourselves when tasked with fixing a bug when we're not dreading having to trudge through spaghetti. When we label code as spaghetti code, we are actually creating roadblocks that hamper ourselves and artificially increase the difficulty of the task at hand.

I just hate talking about frameworks! But as it seems not many people share that feeling so this is an attempt to write a rather short and linkable post on how i approach a new framework and by what standards i judge it. [...] I'm not going to call any names in this post so no need to grab your pitchforks. (For some reason people seem to get really upset when you tell them you don't like the framework the use)

He asks himself a few questions like "can I still write code to my standards" and "how many 'positive adjectives' are used in the description" (inversely related to the quality of the project in his experience). He also talks about one of his other big requirements - being able to actually write unit tests for his code (i.e. the framework must make things testable).

One such example is the register_globals setting in PHP which finally managed to get deprecated in PHP 5.3 (and, the way things are going, may never disappear altogether) after much fighting and gnawing of teeth. [...] The existence of register_globals is problematic in many ways, but it is consistent: as long as you have a version of PHP that supports it installed, you will have the opportunity to use it1. When it is discarded, it ceases to exist, so that rewriting your code becomes a prerequisite to upgrading to a new version of PHP.

He also relates it to a <blink> tag - something that really shouldn't be used any more but, because someone decided it was a good idea in the past, several browsers have included support for it. The moral of the story? Well-planned standards are a good thing.

Microsoft has some catching up to do in terms of standards compatibility, but they are also doing some good things with this browser. They are bringing some much needed web-standards compatibility, in addition to some JavaScript performance enhancements.

Handy new features include better HTML5 support, CSS3 support, XHTML parsing, Javascript compilation and an overall trend towards a more standards-based approach that Microsoft hasn't worried about in a good while now. He also mentions the OData toolkit that lets your web applications speak the same "language" according to Microsoft's more unified specification.

The idea is a wonderful one, and at first things looked like they were nothing but good. [...] At this point, signs of trouble began to crop up, and the good intentions began to result in a chill on the openness with suggestions of reducing input through moderation and discussions of who was a "member" of the standards group. [...] Since then, I have made several pleas, off-list and some on, to open the discussion and move things back to the way open source and specifically PHP works.

Greg's comments are shared by several in the community who wonder why something that could be such a key point for so many applications only involved a handful of the community. Be sure to check out the comments to hear the community voicing some of their own opinions on the subject, both for and against the way the standards group has been handled so far.

It assumes your classes are always declared with the class keyword starting at the beginning of the line and that your files have the .php extension.

It uses a regular expression in a perl command to search through the current directory and look for the ".php" files to replace the "function ClassName" sort of thing with a "function __construct".