In a new article today on PHPMaster.com Robert Mariotti takes a look at standards and how important they can be when developing applications (both in following them and defining them correctly). It's not specifically targeted at PHP developers, but it does give some good food for thought.

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.

Michelangelo van Dam has posted the next part in his "QA in PHP development" series to his blog, a look at PHP_CodeSniffer, a tool that can be used to keep the coding standards of your application in line.

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.

Timothy Boronczyk has a new post to his blog proposing something that any veteran developer already knows - "spaghetti code" is harmful to the health of your application. He's done a little research, though, and tried to explore what this "bad code" really is.

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.

With all of the frameworks making their way around the PHP community, it's interesting to see different developers' takes on judging which is the best for their needs. In this new post to his blog Volker Dusch takes the opposite stance - he hates talking about frameworks.

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).

In a recent post to his blog Marco Tabini talks about the "monkey on the back" syndrome that affects so much of the technology projects these days. His example for PHP? register_globals.

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.

On the php|architect blog today Orlando Medina points out a few goodies in Internet Explorer 9 that could be useful for PHP developers out there.

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.

There's been a lot of controversy around the PHP Standards group that was formed around May of 2009 and how they've handled the decision making process. They want to provide a standard that frameworks and other applications can follow to help making them all play nicely together a much easier process. Unfortunately, they decided to go the "closed source" way. Greg Beaver has posted some of his thoughts on their approach.

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.

Patrick Allaert has put together a shell command that can take your PHP4 code and replace its current constructors with PHP5-formatted ones.

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".

On the DevBots blog recently Darby Felton posted a few suggestions of things that could be done to help improve IT organizations from the inside and promote a more healthy environment for everyone involved.

Lately I have been thinking about a few aspects of the information technology industry. Particularly, regarding software development, I am concerned that the following characteristics remain pervasive and detrimental to our industry: far too many software development projects ultimately fail, we tend to lack clear, rigorous standards and credentials that other industries typically employ, and our [lack of] adherence to ethics and professional conduct leaves much to be desired.

He addresses each of these, pointing out that a good number of IT environments have fallen into these issues and steps need to be taken to: reduce the failure rate of projects, hone down the staff to those that will turn out the best possible product and will uphold a good set of standards/ethics while they do.

On the Zend Developer Zone there's a new episode of the PHP Abstract podcast featuring a roundtable with Eli White, Keith Casey and Cal Evans talking about the future of the PHP language and standards that need to accompany it.

In this episode I sit around a table with Keith Casey and Cal Evans as we ramble on a bit discussing the future of PHP (including PHP 5.3 and PHP 6) as well as talking about the framework standards group that has been formed. This was recorded while at php|tek in Chicago, before PHP 5.3 was released.

As always, there's the same three methods for getting this new episode - grab the mp3, listen in-page or subscribe to the RSS to get this and other great past/future episodes of PHP Abstract.