I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.

So here are the signs your PHP application needs a serious refactoring, right now

Included in the list are things like:

• Uses global variables
• Everything's an array
• The neverending switch
• Interface inconsistency

It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.

To round off an older article on this blog called "Using the PHP 5 reflection API to keep track of unsolved refactorings" I wanted to automate the following task: collect and log some information about developer marked unsolved refactorings for a single class file or more common multiple files of an whole directory. And as I'm getting more and more acquainted with Phing I wanted to craft this custom task by using it's provided extension possibilities.

He gives examples of what the "unsolvedRefactoring" notation looks, the XML mapping for its definition, and the code that actually makes the mapping work - and makes it easy to pull out the needed information. There's two versions presented, one a normal pull and the other modified slightly to "actually retrieve the metadata of the methods marked as improveable via the @unsolvedRefactoring doclet". And, finally, the integration with Phing comes, showing how to run the files and what the results should look like.

Articles in this issue include:

• Anant Narayanan's look at development in PHP-GTK 2 (cover story)
• Eric Angel's tutorial on using random images in form validation
• Stefan Priebsch's thoughts on code structure and refactoring
• and, of course, the Security Corner (with Chris Shiflett) and Test Pattern (with Jeff Moore) columns

You can either order a single issue or get a year's subscription of this great publication. The issue costs about $4.20 USD and the full year only comes in at $35.40 USD.

Most of my work of late has involved refactoring and rewriting insanely large and out of control programs so that it's easier to add features, follow program flow, etc. Since I've been using Rails so much in my personal projects, I tend to refactor things in a way that makes them resemble Rails in a funny, PHP-molested way.

I've come up with fairly decent and clean ways to implement most of the functionality available in Rails; basically, the PHP apps are set up using a frontcontroller, which delegates to instances of page controllers.

He looks at some of the "strange thoughts" he's had in the process, including issues dealing with POST/GET values, session data, and difficulty surrounding the fact that PHP dosen't support multiple inheritance.

To illustrate, he gives a simple example of a function with only a function call and return inside. This has a cyclomatic complexity rating of 1 (the lowest). Now, start adding in ifs, loops, and other ways for the data to go and you start adding more complexity levels. Jim suggests that this can be another useful unit testing measurement - one more unit test for each level of complexity.

He also notes a pleasant side effect of this sort of classification: