Signs of poor PHP ‘products’

If you are a professional developer (or aspiring) you will inevitably get asked to customise or even better “extend” existing wares.

If it’s a product you are familiar with great! If not I heartilly reccomend spending a little time investigating prior to accepting a job ( ultimatley if they are happy to give

access to their code, if not atleast tell you what’s been used so you cam repliocate it to play with briefly). I know this sounds like a lot of work wich ultimatley – if you

don’t accept the job – you have done for free, but it will save you masses of grief, tears and late nights if you do.

So, I have a few pointers to ‘be aware of’ while evaluating the job and to (generally) identify crappy PHP products/solutions quickly…

1. It tries to reinvent the object model, or “fix” language features.

If you can find a class like “object”, it’s a good indicator the author thought he was above us all and wanted to reinvent the wheel! – usually through a lack of their own

understanding. So it’s safe to assume their ‘fixes’ and ‘improvements’ wont end there… My advice run 🙂

2. Code that includes user defined global variables

The global variable is semi-usefull but makes it very difficult to create code that will be understood easily by others. Find lots of ‘globals’ and be wary!

Consider a search  for “global” or “$GLOBALS” in the code may give you something like:

global $database, $me, $main;

If you can tell me what those last two variables contain(or what was done to them prior to a execution at this point) your’e either god-like, or know the code I took this example from!

In short, steer well clear.

3. Disjointed HTML and SQL

Search for common SQL and HTML strings, You should be able to determine whether these are appropriate places for HTML or SQL.

4. Classes do too much

Find the 3 largest class files by size.

Take a look at the class name.

Does it indicate a distinct responsibility? Look at the methods.

Are the tasks they perform closely related?

If not, run away screaming.

5. Lots of properties are public or lots of properties are static

If lots of properties are declared “public static”, double or triple your quote.

If I have to explain why, maybe there’s an open position on the development team of the software for you.

6. Multiple levels of inheritance

More than 2 levels inheritance should be avoided, the resulting objects will probably have too much unrelated behaviour. Again, double or triple your quote.

7. Use (or attempted use) of Design Patterns

Whether or not the creator has/had a clue will be easily determined by searching for some of the most common design patters.

Search the code base and/or documentation for “factory”, “decorator”, “strategy” etc.

If present, you can pretty quickly determine whether they knew their stuff or are trying to look interesting.

That is, if you know how the code should look. If not, refuse to take the project until you do.

8. The software messes with the error level

Well written applications run fine at any error level.

Searching the files for /error_level\(.*\)/.

In case of hits, try replacing the value with E_STRICT to see what really happens 🙂

Not the worst thing they can do… but worth doing to check for any hidden surprises!

9. In the code base, there is a directory called “core”

This is usually used as an excuse to have the whole application dependent on whatever is in there. In short, defining a “core” is usually the sign of bad design.

10. Has it’s own ‘template language’.

Be afraid. Very afraid. Ignore this warning and you will find yourself spending the better part of a day simulating a “for” loop to display a record set!

Leave a Reply