Clay Loveless has an excellent article on professional PHP development attitudes.
I couldn’t agree more about the rules, especially that last one. My own PHP coding (in pretty much the exact circumstances described!) has come on by leaps and bounces in the last year by learning svn and simpletest amongst other things. I regard the use of E_STRICT much in the same way as W3C validation of XHTML and CSS – it’s vital. I encounter many designers that don’t comprehend validation – the excuse that things don’t work the same in IE seems to give them carte blanche to make a complete pig’s ear of everything. Having said that, E_STRICT is hard to maintain with many external packages, particularly bits of PEAR. The forthcoming undeprecation of ‘var’ should clear things up quite a bit, though I don’t know if we’ll have to wait for PHP 6 or if it will sneak into 5.x.
Lately I’ve been looking into PHP IDEs (again). I’m playing with PHPEclipse. It has some great features, but I really don’t get how anyone can be all that productive in a single window IDE! I’ve been having a hard time making it do what I want, and there are just endless amounts of configuration to be done. Even when it’s all working, it just seems much slower and more cumbersome than a few terminals and a copy of BBEdit. Ideally I’d like an interactive PHP debugger in the IDE, but DBG doesn’t seem to want to play nice on OS X, and it doesn’t support PHP 5.1 anyway. I might have to see what xdebug can do in that direction.
Just to add to the error_reporting confusion, PHP6 is scheduled to change it again. From Derick’s PHP 6 meeting notes (which seem to have mysteriously disappeared from php.net):
As we want to expose the language level warnings a bit more, and because of having all error levels in E_ALL, except E_STRICT is confusing we will be adding E_STRICT to E_ALL. As the current default is E_ALL & ~E_NOTICE we will effectively turn on E_STRICT by default.
In a reply to the blog entry, Xing Li said
To control peformance is to shed fat, use lean code, and control i/o follow from point to point and through every single line of code.
While I agree that it’s the way to go for small-scale efficiency, it’s often difficult to do in the large, and is prone to the ‘early optimisation’ trap. To deal with the larger scale issue, I’m surprised that more people don’t seem to use profilers. xdebug‘s profiler pumped into kcachegrind is just a wonderful thing for PHP development, and runs great on OS X.