While working on an issue with debugging a script of his via XDebug, Derick Rethans was reminded of something that is an integral part of the PHP language - its two phase compiler.

During the first pass, it will find out to which opcode it needs to jump in the jump instructions. However, the PHP engine (and Xdebug) expects a memory address to jump to while executing your script. In the second pass, the compiler will then go over the generated opcodes and calculate the memory address to jump to from the jumps to opcode numbers.

Because of the way that XDebug was handling the checks (with the user-defined error handler) and how the opcodes inside of PHP are handled, the user-defined handler happened in between the first and second phases and the latter run couldn't find the resources it was looking for, thus the crash.

In a great new post from Alan Knowles he takes a look at code reviewing, specificaly in a PHP environment.

He breaks the post up into phases (one through four) with the steps outlined along the way (including the "oh sh*t, it's getting urgent, we better fix the delivered code and make it work well enough for the client to start testing" phase). Phase four is the largest, being the bug finding and fixing stage, some of the more intensive (and sometimes numbing) times of development.

He also includes a good, long list of some of the codeing standards he's accumulated over time, including:

• Not creating PHP includes with functions in them!
• Never hard code email subjects etc. in code, use templates.
• Not using libraries that where not specified.. or using non-PEAR libraries when PEAR ones are available...
• Everything extends the base class, even code run via cron jobs.

He also talks about using print rather than echo, exiting on XMLHttpRequest calls, shortcuts in Javascript, and cloning dataobject arrays over creating simple structs.