Some say PHP ain't a serious tool. I can't agree with that, but the fact remains that PHP lends itself to horrible hacks. To avoid horrible hacks you need to be structured, disciplined and hasten slowly, three qualities not associated with the hoards of PHP programmers out there. Anyways, there is a handful of tricks I use in trying to keep my PHP lean and mean.

Now, the reason you hack is to get something up and running quickly. Very often we create a prototype that according to legend has it will be a prototype upon a new specification is molded. This never happens; the time we've got and the push we receive often result in the prototype code is refactored into whatever project have you. This lends to crap design and poor code.

Crap design

Every little PHP functionality I put in a file named appropriatly, even if the files name is "crap_workflow.php." Even the smallest modularity is gold when you refactor your crap bits into usable bits. I also create a set of global variables that store the place to where these files can be found. Hence, includes galore;

define ( "MY_MODULES", "/usr/local/b/bu/php/modules/" ) ;

require_once ( MY_MODULES."crap_workflow.php" ) ;

The MY_MODULES you define at the top-level PHP file can be used willy-nilly where you need it, and it will keep your nested directories from screwing up.

Error checking

PHP5 promises us better error checking, but until then (and given the vast amounts of existing PHP code out there) here's what I do; have all warnings, errors and notices ON. Yes, turn all flags on. Ahooogha! Ahooogha! This practice will yield heaps of messages about unset this and unassigned that that you know - deep inside - will still work, because that is the way PHP works. Which is a selfish stupid trap to fall into, of course. Here is the remedy;

Initialise all variables with blanks until used. In strongly typed languages like Java and C/C++ this is a must, and it has proven itself quite valueable to me over and over. Yeah sure, that you don't have to gives you the freedom not to. Luckily with all warnings and messages turned on, you'll see all the undefined clutter you've got lying around. Just initialise. And if you keep these to the top of your functions and methods, the better;

$someVariable = "" ;

Further, if you come to a spot where you know that often you will have errors but due to time restrictions (we are hacking at this point, you know) do this;

$someVariable = @someFunctionThatMightFail() ;

Notice the '@' in front of the function; this turns off errors and such for this function only. When you later refactor this, it is this very '@' that becomes the error handler. It makes it easy to catch future 'Oh, oh!'s.

OO

The dream of true Object Oriented programming falls slightly short in PHP up until the upcoming PHP5, but it is still a very nice way of abstracting data and interfaces. Keep your classes in seperate files (as explained above), and include at will. Now, dependencies is the biggest bum-biter here, so if you don't have to have one object depend on another, then don't. It is a source of many evil bugs.

Wrappers

The best way to survive a horrid prototype -> refactored working project is to put wrappers around things you don't understand or that is somewhat complex. (And complexity is metered in 'if I look at this code in a month, will I still understand it?' If no, then you need a wrapper around, so it is ready to undergo serious refactoring in the future;

function zxDefaultFactoryNose ( $factory, $trigger, $param, $diff ) {

... some horrid complex code here ...

}

You have the above, and need a wrapper;

function oneWayIKnowThisWorks ( $singleParameter ) {

$factory = getFactory ( $singleParameter ) ;

$trigger = "23;45;34" ;

$param = "" ;

$diff = "xt=trim(4)" ;

zxDefaultFactoryNose ( $factory, $trigger, $param, $diff ) ;

}

See? All ready to be refactored at a much later stage when the functionality of zxDefaultFactoryNose() a) gets figured out, and / or b) expands.

Comments

For super-geeks, there is JavaDoc that extract comments from source code, and builds source-code documents from them. You can do the same in PHP, wheter you'll actually use the extracting tools to get them; the comments are very handy, so even in a quick prototype, take your time to write something ;

/**

* oneWayIKnowThisWorks function; wrapper for complex function zxDefaultFactoryNose().

*

* @param string $singleParameter Explanation of this parameter

* @author Alexander Johannesen <>

*/

function oneWayIKnowThisWorks ( $singleParameter ) {

...

}

Naming

A pet burden amongst many geeks is the naming conventions of variables and functions/methods. Here is mine, in short;

$aListOfFish ; // Array

$sName ; // String

$vSomeValue ; // Value; int or otherwise

$oUser ; // Object

The names I try to make understandable as much as possible. Being into Topic maps and the semantic web, I try to create names that carry some semantic value. So instead of;

$i = 0 ;

for ( $i=0; $i<100; $i++) { ... }

I would do;

$currentItem = 0 ;

for ( $currentItem=0; $currentItem<100; $currentItem++) { ... }

Yes, I type a few more characters that way, but when you go back to your code - and especially considering the complexity inside your for loop (and given we're talking about prototyping here, I can only speculate to the horrors inside ...) - these more semantically valued names will make your code self-explanatory instead of a cryptography excercise. Oh, and this is one more variable you don't have to refactor later. Save yourself some time.

And there you have it; my quick and rough guide to quick and rough programming in PHP. Next; how to write short Java code. (Hmm, no wait; that is quite impossible. Nevermind.)

Permalink (Thu, 11 Mar 2004 13:00:00 GMT)| Comments (3) | Programming Methodology

An interesting interview with Andrew B. King over at Digital Web Magazine that speak about web-page optimization; why it is important, where you do it, and the psychology involved from a users perspective. A good interview highlighting many of the same things I say about accessibility and methods of web development. A nice read.

Permalink (Fri, 16 May 2003 13:00:00 GMT)| Comments (0) | Interface and interaction design Methodology

The purpose of this article is to a) give people - like project managers, sales, customers and other developers - an insight into what a web user interface developer does and doesn't, shoulds and shouldn'ts, and b) give web user interface developers insight into methods, best-practices and decisions me and my colleagues at bekk not found. do every day.

Permalink (Mon, 28 Apr 2003 13:00:00 GMT)| Comments (1) | Interface and interaction design Project management Programming Methodology