PHP-FIG member Paul M. Jones and PHP contributor Anthony Ferrera come on the podcast with Ben, Phil and regular guest Zack Kitzmiller to discuss the new Package Orientated Autoloader Proposal (a.k.a PSR-X), and wether or not PSR's should ever be amended.[...] Nobody wins, but the argument brings up a lot of interesting topics and points of view, and that is mostly what we are here for.

You can listen to this latest episode either through the in-page player by downloading the mp3 or by subscribing to their feed. The post also contains links to several of the groups and technologies mentioned in the episode.

A little background for those unaware of what PSR-0 is: There's a self-declared PHP "standards" group called PHP-FIG attempting to push several "standards" throughout the PHP community. [...] I have little interest in debating the politics behind pushing standards or whether small groups of developers trying to make decisions that affect the entire community is good or not, but I do object to the PSR-0 standard itself. My issues are purely practical, PSR-0 reduces flexibility and makes life more difficult for developers

While he likes the idea of a standard way to be able to include third-party libraries that can be reused in multiple systems, he suggests that it answers the wrong question. In his view, it should be up to the library/tool developers to ensure the structure of their code to work with a standard, not the other way around. He points out that a "standard" is something that should apply to all situations and some of the workarounds that are needed for PSR-0 negate this idea.

In his alternative method, he suggests an "Autloadable" interface that can be implemented by the library/tool that includes a "load" method to handle the actual class loading. Then this autoloader would be registered via a json configuration file for the package. This allows the developer to control the loading and place any exceptions they might need into their own logic instead of trying to work around possible issues with the PSR-0 loading scheme.

PSR-0 is a bad solution to a good problem. If you take anything from reading this post, remember this: If the standard defined how autoloaders could be extended, rather than how autoloaders worked, then each library or vendor could provide its own extension to the autoloader and everyone would be happy.

[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

Whenever you're working on a project, are you consistent? Are you consistent in your coding style, consistent in your documenting, consistent in your database naming conventions? Better yet, do you and your team have a coding standard which you consistently adhere to? If you don't, you're buying yourself and others a world of pain - which is painlessly simple to avoid. Today I'm banging the drum, shouting from the street corner, calling from the cathedral spire, imploring you to do one thing, above all else - pick a coding standard and then BE CONSISTENT!

His five reasons for implementing (and effectively using) a coding standard are:

• Poor, Inconsistent Code - Causes You Pain
• Your Code is Easier to Read
• Your Code is Easier to Understand
• Your Code is Easier to Maintain
• Your Code is Easier to Collaborate on

Check out the post for summaries of each point.

First, I should state that I'm not a member of PHP-FIG. I applied to be a member representing the Elefant project, but saw projects with similarly-sized communities rejected, so I wasn't surprised at the lack of response to my application. However, I do agree with the general goals of the project and think it has a lot of potential if steered well.

He then spends a good bit of the post talking about the three PSRs (autoloading with PSR-0 and coding standards with PSR-1 & PSR-2) and how he thinks the PHP-FIG has some "public relations" issues they need to overcome as it relates to their reactions.

PHP-FIG has grown rapidly since its inception, and with that comes the need to reevaluate and adapt. The PHP community is huge, and a group hoping to represent even a substantial minority of it will have to practice diplomacy and clearly state its intentions if it doesn't want to be misunderstood or cause alienation amongst the wider community.

There's also some good comments on the post so be sure to check those out too.

If you're an avid PHP developer, it's quite likely that you've come across the abbreviation, PSR, which stands for "PHP Standards Recommendation." At the time of this writing, there are four of them: PSR-0 to PSR-3. Let's take a look at what these are, and why you should care (and participate).

They start with a brief history of the standards, the PHP-FIG (Framework Interoperability Group) and where the idea for the PSRs came from. Then the article gets into the details of each:

• PSR-0: Autoloader Standard
• PSR-1: Basic Coding Standard
• PSR-2: Coding Style Guide
• PSR-3: Logger Interface

They also do a good job mentioning some of the criticism that's come with the standards and what sort of future there is including the creation of a standard for a HTTP messaging package.

Coding style is how your code looks, plain and simple. And by "your," I actually mean you, the person who is reading this article. Coding style is extremely personal and everyone has their own preferred style. You can discover your own personal style by looking back over code that you've written when you didn't have a style guide to adhere to. Everyone has their own style because of the way they learned to code.

They talk about how everyone has their own personal "style" to their code and how, when working with a team, everyone needs to communicate and make sure their styles match. They also make a few recommendations for your code like leaving "clues" (comments) and making errors easier to spot. There's also a few links to tools that can help keep your code standardized including CSS Lint and the Eclipse code formatter. PHP, of course, has its own - PHP_CodeSniffer with its own rules.

Earlier today, the PHP Framework Interoperability Group accepted two standards recommendations. [...] There's been a lot of commentary about these proposals over the past two weeks, some of it positive and some of it negative.

He includes links to some of the commentary that's been made about the standards recently, and spends some time responding to some of the negative comments specifically, like:

• What the hell is the "PHP Standards" group? I've never heard of it before now.
• Why are you guys so secretive and closed?
• So once I join the list, I can vote on PHP-FIG Standards Recommendations? Sweet!
• Whatever. I don't need you guys telling me what to do. If I don't want to follow your so-called "standards" then you can't make me.

They initially started out as one proposal but the initial round of voting didn't yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.