About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

PHP Advent Calendar Day 8

Today's entry, provided by Matthew Weier O'Phinney, is entitled Don't Reinvent the Wheel.

Matthew Weier O'Phinney

Matthew Weier O'Phinney
Matthew Weier O'Phinney is currently a PHP developer for Zend Technologies, and is lead developer for the Zend Framework MVC and server components. He has a number of open source contributions under his belt, and wishes he had more time in the day for raw coding.
Richmond, Vermont

Developers are a strange breed; we all know that others have developed libraries and components that we can use, but we have an almost insatiable desire to do it ourselves. Some call it the NIH syndrome; others feel they can do it better, or simpler, or faster. We all succumb to it at one point or another as we mature as developers; I've heard the quote that the average PHP developer has developed 2.5 frameworks.

However, writing your own code all the time is a serious waste of your time. Why write yet another RSS feed parser, or another data table gateway, or another logger, or another mailer? The time you spend doing these things is time wasted; you can get more work done using somebody else's code, which ultimately means you can complete more projects and earn more money (or help a non-profit organization achieve its mission).

Additionally, a good developer repeats the mantra Don't Repeat Yourself to themselves constantly. While this typically means avoiding code duplication in your source tree, it can easily be extended to mean Don't Repeat Others. Don't go rewriting what others have already written for you.

Finally, with well-established projects, you benefit from having had many people review the code. This means that most design issues will have been resolved, often by people smarter than you (or by collective intelligence), and many, if not all, bugs will have been identified and fixed. It also means that the community will continue to fix problems, and you won't necessarily need to.

PHP has been around for a good many years now, and there are many places you can look to for quality code:

The Standard PHP Library is a set of interfaces and classes that have hooks into the language and allow for a lot of sophisticated OOP usage. I've seen a number of people wanting to create Container or List classes; look no further than ArrayObject, which allows you to create classes that can also look and feel like arrays, including letting you sort the items.
The PHP Extension and Application Repository has rigorous requirements for accepting new components. Perhaps its greatest strength, however, is its collection and establishment of standards: how to document your code, requirements for testing code, and more. Components written for PEAR tend to be very high quality.
The PHP Classes Repository offers little barrier for submission, but the user ratings allow you to filter and find those that other developers have found most useful or best implemented.

In addition to these, there are a number of competing component libraries and frameworks:

Many of these projects require their developers to unit test the code prior to release; for you, the end-user developer, this means you can be assured that the code will work as specified, and continue to do so in the future as new features and improvements are provided. This will in turn save you additional time, time not spent debugging when an upgrade is performed.

So, next time you need to add a feature to your site, consider searching to see if someone else has done so already. If you find someone who has, but the code doesn't live up to your standards or needs, instead of dismissing it and starting your own, try collaborating with the author. This way, others can benefit from your skills as well, and you don't pollute the Web with yet another solution to the same problem.

About this post

PHP Advent Calendar Day 8 was posted on Sat, 08 Dec 2007. If you liked it, follow me on Twitter or share:


1.Travis Swicegood said:

Hey Matt - I couldn't agree with you less :-) Well, at least in spirit. If things need to get done, and need to get done quick, then sure, glue some pieces together and get it off of the ground. Hopefully, you'll have the functional tests in place to allow you to refactor later when you can/need to go back and make it scale, perform, maintain, or just look - take your pick - better.

At any rate, I think a developer learns a great deal from re-implementing a table data gateway. Or seeing for himself how a table module and row gateway interact with each other and their role in a domain model. Should they be coupled? Why or why not? How else could it be implemented? That kind of knowledge comes almost exclusively from experimentation and gives a programmer experience he can't learn from a book for those times when he must go out write from scratch for whatever reason. I think patently labeling one's efforts at extending their knowledge and sharing it with others as a "serious waste of time" is at best a disservice to them and at worse a disservice to the community as it might stunt a possibly great mind.

There are competing interests here, however. Often, a developer's time isn't his own and meeting deadlines becomes more important than making yourself more valuable to a company. In those situations, I encourage anyone to glue away during their 9 - 5, then start quietly posting their resume. ;-)

Sun, 09 Dec 2007 at 02:31:44 GMT Link

2.Bruce Weirdan said:

Sources of "quality code" seem funny - most PEAR code is mediocre at best, and it's usually much faster to implement something yourself than to debug an implementation from PHPClasses

Sun, 09 Dec 2007 at 21:12:55 GMT Link

3.Mike Coughlin said:

... all swell - in theory. Arguing against code re-use would be like arguing against motherhood and apple pie. Like most things in life, the devil's in the (implementation process) details. We'd all like to do it, BUT ...

I think that the biggest restrictions on code re-use are:

#1 FINDing appropriate solutions and

#2 documentation.

Regarding #1, would a central code directory service be neat?

Regarding #2, even when best intentions exist to document, when updates/revisions/refactoring occurs, documentation is seldom updated, concurrently ... rendering the original good documentation intentions out of date. Let's face it, coders are not natural documentors; they HATE documenting. They don't even comment their code when on their best behavior, like providing code examples for books they write! So, how might they take advantage of the automatic documenation (updating) schemes, which depend upon commented code? Looking at most code, you'd think we were back in memory-constricted assembly language days.

In the absence of great documentation, most think "I could re-write this faster than I could figure out how this code works."

Just like good testing involves coding to test code, good documentation starts with coding to designs (e.g. UML diagrams or whatever). How many abide by these 'best practices'?

... and so it goes ... unfortunately.

Wed, 19 Dec 2007 at 05:07:54 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.