Xing: You’re absolutely right about knowing what’s going on in each line of code. Ideally, in a well-formed class/package, there’s been some thought put into segmenting out the essential pieces so that you’re not required to load up a bunch of overhead crap just to use a method or two. As for LoveCookies.com — after putting on too much weight running that effort, plus having our first child, my wife and I decided to close that down. Was a great learning experience, though!

Shawn: Ultimately I just came to the realization that for now, if you want to use PEAR libs, you can’t run under E_STRICT. Slowly but surely more and more PEAR packages are evolving to E_STRICT compliance, but I suspect it’ll be another year or two before we get there. In the meantime, I’ve been developing with Zend Studio 5 and running the “Analyze Code” routine over my code and checking to make sure that the debug output isn’t complaining about E_STRICT problems in what I’ve written. That way I’ll be in the clear when my dependencies are E_STRICT-ready.

Paul: I agree — some core competencies are certainly a pre-requisite. However, I feel like otherwise mediocre-to-poor developers can be made passable through the adherence to some Best Practices.

After all, even my grandmother can grasp a ’switch’ statement; she executes one every time she goes out to run errands. “If this store is too crowded, go to this one instead and pass back by the first one on my way home…” and so on and so on.

I ran across a really good blog entry by Clay Loveless (of Feedster fame) yesterday that really cut to the heart of what it means to call yourself a software developer. In his words: discipline. I highly recommend everyone who considers themselves a de…

You are very welcome. Thanks for the great blog.

> I stuck with E_ALL in the Feedster frontend re-write since it depends on so many PEAR libraries which aren’t E_STRICT compliant.

I’d love to know how this worked out for you in your development efforts. I too use a LOT of PEAR libs in my applications and almost all of them throw tons of notices when strict reporting is turned on.

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 bounce…

While I agree with your statement about not making everything into objects, however, if you are working on a bid enough project it makes more sense to make them into objects. Each object contains a layer of functionality along with a the code that implements these routines. This allows you to do many different things.

One of them being consistancy which you complain about earlier. Also in most objects you shouldn’t need to use a constructor. It might just be bad design when you are looking at some of those.

Allowing for static methods you can utilize an object somewhat like a namespace which then allows for much more consistancy. Controlling the flow of performance is almost just as great if you utilize your objects correctly, if not sometimes better.