In a new post to his blog today Anthony Ferrara looks at the (heated) discussion that's popped up around having the PSR-0 autoloader standard included as a part of the PHP core. He gives his reasons (three of them) why he's not for the decision.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

On the Liip blog there's a new post that compares some of the popular PHPDocumentor-formatted comments parsers. They're looking specifically at the support for interfaces, not just the usual classes and methods.

The interfaces define the standard and are extensively documented. The implementation was built by copying the interfaces and implementing the methods. Now we have the documentation comments duplicated, which is a pain to maintain if we clarify or change anything in the interfaces documentation. [...] In PHP, there is a couple of doc compilers. While they basically all follow the same syntax as Java uses, none of them gets everything right unfortunately.

The four covered are PhpDoctor, DocBlox, PHPDoc and Doxygen. They look at things like namespace support, the inheritance information they generate and if it correctly uses the "@inheritDoc" tagging functionality.

Volker Dusch has a suggestion for all of the PHP projects (or, really Open Source projects in general) that can help keep things cleaner in your codebase and make for simpler times when merging contributions - including your coding standard along with the rest of your project.

Let me elaborate on [an important] point: Contribution. Most developers i know care about producing good code, especially then they are contributing to an open source project! Those people will respect your coding standard, naming scheme and every thing else that they can check for before sending you all patch/pull request. So try to make that part easy.

He talks about doing things the hard way - reformatting everything by hand each time someone contributes - or the easier way of enforcing the coding standard as a part of the contribution flow. He mentions PHP_CodeSniffer and the PHP Mess Detector as a part of a Jenkins installation (easily built from this handy project).

On the Mayflower blog today there's a new tutorial posted about creating coding standard "sniffs" for the PHP_CodeSniffer tool. A "sniff" is what defines the rules for your coding standards to follow (like "curly braces after function definitions should be on the next line" kinds of things).

In some cases the pre-installed coding standards like PEAR or Zend might not be sufficient for our current project or we want to deviate. This is the moment when we want to be able to create a custom one that fits our special needs. In this article I want to share my first experiences with you about how to create a custom coding standard for PHP_CodeSniffer.

They get into the details of what a "sniff" is and shows where they belong in the current structure of your PEAR install. There's an example of how to run the command line tool and how to create your own structure for your own custom sniffs. Their first example sniff checks to ensure that the first letter of a class is in uppercase.

On the Nefarious Designs blog today there's a new post looking at something that can be a key in the strategy of a development group - creating a coding standard.

In my time as a web developer, I have been involved in the definition, implementation, and maintenance of several different coding standards, across various web-based languages. In my experience, this process is not as straightforward as it first seems, and can lead to a great deal of headaches if not handled in a very specific manner.

He talks about why a coding standard is even important and some of the first steps you and your team can take towards creating them. He breaks it up into a few different sections:

• Comments
• Naming conventions
• Style (ex. tabs versus spaces)
• Already accepted standards
• Expressions
• Concerns over file size

Developing applications has become simpler and simpler these days and the multitude of IDEs out there can help you keep all of your files organized and linked together so you know everything is in its place. There's one thing that only a handful out there can do, though - enforce coding standards. Thankfully, there's a tool that can help you keep your code following down the right path and PHPBuilder.com has a new tutorial about using it - PHP_CodeSniffer.

Although defined according to formal grammar and syntax, programming languages -- like their spoken counterparts -- often leave their users with a great deal of leeway for creative expression. [...] It can even be singularly counterproductive if you do not maintain stylistic consistency across projects, as you'll need to continuously re-acclimate to differing syntactical variations.

The PHP_CodeSniffer tool runs your code through a validation process and checks its structure against a coding standard (like the PEAR standard) and ensure it's formatted correctly. The tutorial shows you how to use the "phpcs" executable to test PHP, Javascript and CSSS files (using the Squiz standard).

In a new post to his blog Leszek Stachowski wonders about a coding convention that's still widely used when it comes to private methods in a class - the underscore prefix.

The question which comes instantly to my mind is: why? Is there any reason why this convention should be kept when PHP object oriented programming has gone a long way since PHP 4 (when there was no access modifiers and such underscore was the only fast way to distinguish public from, hmm, not public methods and properties) ? Are, for instance (as one of major OOP languages), Java coding standards pushing towards such naming convention? No!

He, like many other developers, are pushing to drop this kind of convention as an outdated reminder of the PHP4 days when "private" didn't exist in the language. Scope modifiers have done away with the need for that underscore completely.

Kevin Schroeder has the latest excerpt from his book posted ("You Want to Do WHAT with PHP?") with a focus on the SPL - Standard PHP Library. He specifically takes a quick look at Iterators.

If you are doing any data processing whatsoever you are using arrays. And most likely you are doing database queries, iterating over the results and doing your algorithm-ing. But what if you have additional functionality that you need to have integrated with your data. You could go the traditional route and copy and paste half your application around or you could build, what we like to call structured applications. SPL allows you to do that.

In the excerpt he mentions the methods that come built in to Iterators like rewind, current and valid. There's also some sample code showing a custom iterator that works with some user data to output the information set in the constructor. You can find out more about this chapter and the rest in Kevin's book.

Matthew Turland has a new to his blog today about some of the new SPL features in PHP 5.3 (and was eventually made into this presentation).

The SPL, or Standard PHP Library, is an often overlooked extension in the PHP core. It first came on the scene in PHP 5 and a variety of iterators constituted the majority of its initial offerings. Though the iterator offerings were expanded in PHP 5.3, the particularly interesting additions to the SPL were several specialized data structure classes, the foundational concepts for which originate in the field of computer science. In this post, I will provide an overview of these new classes and explain why and when they should be used.

Matthew talks about some of the new advancements in working with arrays, creating fixed arrays, handling lists (linked and doubly-linked), stackes, queues, heaps and hash maps. He also includes some benchmark information and graphs of some tests he ran comparing the SPL methods to some of their normal PHP counterparts.

In a new post to his blog Klaus Graefensteiner takes a look at a quick way you can enforce your set of coding standards right inside of the Eclipse IDE with the PDT extension installed. It's not the easiest thing to do, but if you have a well-defined coding standard and know you'll be enforcing it strongly, this might be the way to go.

I recently came across a nice collection of coding standards that the developers at Gallery2.org are using. I especially liked the summary of settings for Eclipse PDT. I applied them to my Eclipse PDT development environment, took some screenshots and put this article together for my personal reference:

Settings he changes include some of the general editor settings (like tab width and margins) as well as PHP and source control specific settings to remove extensions the IDE doesn't need to worry about. He also mentions the "Code Templates" feature that allow you to get more specific and define the standards at the code level, not just the editor.