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.

I think most of the people using PHP wonder from time to time about particular behavior of the language. [...] But lately I stumbled over a nice one. It looked like a bug in PHP, but turns out to be an interesting, curious, part of the C-language.

He gives an example of a case where an error message (as a result of E_ALL error reporting) shows evaluation of certain variables in a different order than anticipated. As it turns out, the difference was in the order of the parameters in the C code of PHP (different on SPARC versus x86 systems).

There is too much old advice in PHP. A recent case comes from the PHP Advent calendar. Eli White is a strong believer in commenting code, including inline comments inside functions. Unfortunately, he's at least 10 years too late. This used to be good advice, but not any more. Up to a point, he's right.

They propose a better way - refactoring code so that its as easy to read as possible, reducing the need for extensive commenting. They illustrate with a rework from the Zend Framework function, changing up the method names to better reflect the action inside (rather than the current "doUpdate").

Nate Abele and Larry Masters join me to discuss the new FormHelper feature in CakePHP 1.2. This time we manage to stay on topic and sober. Join us for an archived hour of form developing goodness.

You can either subscribe to their normal feed, their iTunes feed or you can just grab the show directly from the site to enjoy the episode.

Clearly I touched a nerve. However I did learn a lot of things that you don't read in a quickly tutorial on PHP. The whole point of writing something is to get feedback, positive or negative, and hopefully learn from it.

He admits that his experience with PHP and its developers has been limited, so his perspective might have been thrown off a bit. He still holds to one thing from the previous article, though - that PHP just isn't for him.

Still the practice of using objects in PHP remains a bit of a lost art - you're more likely to find an application with a bunch of functions than objects. PHP just lends itself to function-like thinking.

That doesn't mean that you shouldn't take advantage of the object-oriented (OO) features of PHP. The big question is when. Deciding when to implement a bit of code as an object or as a function is the real trick of object-oriented programming (OOP) in PHP (or as I like to call it, POOP). If you get that right, you can save yourself a lot of time and hassle down the line.

Jason starts off with the differences between OOP and regular, procedural programming, explaining it with a series of reasons/times to choose OOP. Of course, code examples are a must, and a few are included, showing the structure of classes and how to create new objects from them. He explains the PHP5 functionality offered as well, including private/public/protected values and functions.

They seperate it out into three different sections - setting out your performance goals, analysing your site for current traffic/resource consumption, and the actual implementation of the performance settings. They give a few steps here to follow to check what your server is currently using and some links to other tips on tuning the various pieces of the puzzle.

One thing that they mention that's worth repeating to any and all web developers out there: "Apache is bandwidth limited, PHP is CPU limited, and MySQL is memory limited and disk I/O bound".