This is the first article of a series I will dedicate to tips to write PHP code that is easier to maintain, review, refactor,... These tips may be applied for other languages but are mainly focused on PHP. The first one could be entitled as "return as soon as possible.

He compares a code example - simplifying multiple if/elses, replacing the need for multiple nested evaluations that make the code harder to read. Check out the before and after to see how it helps the flow.

Some time ago, Vince, a seasoned PHP developer, asked me to have a look at his very first symfony project, a product store. As the mistakes he did were quite common, I decided to tell you the story of this refactoring session in the hope you will learn as much as Vince did

Here's links to each of the five parts:

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5

One of the most fundamental decision in object design is deciding where to put responsibilities. No one, and I mean no one, gets it right the first time. That's why refactoring is so important. As Kent Beck puts it, refactoring is the process of taking a system and adding to its value, not by changing its behaviour but by giving it more of these qualities that enable us to continue developing at speed.

He follows the "extract" refactoring method that makes things simpler by removing unneeded parts of the code (in favor of an interchangeable external "extract class". He removes seven methods from the class and splits them off into their own. This reduces the controller down to a more manageable size and takes a lot of the complexity out.

His list of four is:

• Doc Comments
• Flexible Parameters
• Use method Entry contracts
• Be Stateful and Refactor

The "Doc Comments" is pretty obvious, but some of the others need a bit more explaining. Being flexible with your parameters is more about requiring the least from a developer, "entry contracts" being the restrictions to let the developer know what you're expecting and refactoring commonly used functionality into a easy, single point of contact.

At first, refactoring seemed to me to be magic, over the years I have come to view it as more of a trick, and today refactoring is integrated into my development environment and used frequently and quickly. Using the refactoring functionality, in addition to other tools, I can sculpt the code to improve legibility and maintainability.

He talks about why PHP developers should jump on getting to refactoring their code, the different forms of refactoring, code examples showing it at work and some development tools/resources you can use to dig a little deeper.

Over the past few evenings, I've refactored File_Fortune to have it implement Iterator, Countable, and ArrayAccess -- basically allowing it to act like an array for most intents and purposes. As a result, I've eliminated the need for the File_Fortune_Writer package, and greatly simplified the usage.

The package is designed to make an interface between the casual PHP user and the fortune files common on most *nix machines. To illustrate he update, he includes some code that grabs the fortune file, parses it to grab a random one and echoes them out. Also included is the save() method so you can add your own to the list easily.

From the first post:

As a follow on from my previous entry about OpenID in the Zend Framework, I've been in brief contact with Dmitry Stogov across a scattering of emails. Dmitry posted his OpenID proposal for the framework over at the Proposals Wiki earlier in the week. [...] It's actually very hard to comment constructively rather than simply handing over my code which probably says a lot more all by itself. [...] Anyway, I've agreed to port my OpenID library to PEAR as a PHP5 package. I checked with the mailing list, and the approach I've taken in splitting the library across a number of freestanding components hasn't seen any objections. On the flipside, it does help by providing upgrades to existing PEAR Encryption packages which are not yet migrated to PHP5 versions.

And from post number two:

Over the weekend, I managed to grab a few hours to dig around my OpenID library with the ultimate development tools: patience and experimentation. [...] What I've refactored towards is a splitting of the OpenID process based on three categories: Request, Redirect, Response.

In the past couple weeks, I've refactored it to push the class/function reflection into Zend_Server_Reflection, and, in doing so, noted that there were further areas for refactoring into additional helper classes. Currently, it now has classes for the Request, Response, and Faults, and all actual XML wrangling is done in those, making the server basically XML-agnostic.

The refactoring of the code also had another positive side effect - it made it much simpler for him to write up the tests to ensure the correct functionality of the package. He includes an example of the use of the package, a fake request with various methods in the comb, brush, and pick categories.

If you'd like to mess with the extension yourself, check out the Zend Framework subversion repository and grab the latest incubation distribution.

So far I've had tons of fun trying to create php code using test driven development. It caused my code to become a lot more structured/consistent because writing the tests shows you interfaces problems right away. This is because the process of writing the test forces you to think a lot more about *how* you want to use some class / piece of code vs. your traditional "how can I get task x done"-thinking.

He also points out another benefit - it makes refactoring the code even easier (so there's more of a likelyhood that you'll use it again and again). He talks specifics about a library that he's been working on and the processes he's gone through to make things work with the testing versus his normal development cycle.