Popular links

Topic maps

xSiteable

Claudio Monteverdi

Alexander Johannesen

Technologies used
topic map logo
xSiteable logo
Thu, 11 Mar 2004 13:00:00 GMT

Notice! This blog is no longer updated as such, and the new spot to point your feedreaders and blurry eyes are https://shelter.nu/blog/

This also means no more comments here, and especially not you spammers, you filthy floatsam of the internet!

PHP Prototyping

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
( Sat, Mar 13 2004 )
Neat tips and tricks. I rarely code any PHP these days, but when I do, I will keep your tips on the top of my head! :-)
( Wed, Apr 7 2004 )
I'm going to have to disagree on a very minor point of an otherwise ingenious article:
---begin quote---
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
---end quote---
Most excellent point on making the names as understandable as possible, and for the most part, these names are. However, they meet the criteria for an item on that Object Oriented Programmer's list of horrors: Hungarian Notation. I know this has been debated in countless flame wars, but hungarian notation violates the spirit of Object development. Yes, it provides a hint for the readers of the code, but it flounts the flexibility that polymorphism (one of the 'holy three' in OO-land) promises. If you're going to write Object code, then all your variables must be prefixed with an $o, since in good polymorphic code, everything could be an object. The method or methods calling functions on these variables or being handed the variables should do the right thing... why should we impose unnecessary restrictions on them?
On a more practical level, I can't tell you how many times under a Hungarian Notation regime that I've had to refactor a method to handle more than one type and have had to hassle with changing countless calls and names of variables to then 'new' prefix; only to change my mind yet again and go through this renaming all over again. Eventually it builds up a resistance (due to laziness) to refactoring, an activity that should be encouraged above almost any other in a good development shop.
ryan
Alex ( Wed, Apr 7 2004 )
Well, I agree that in a 100% OO project, Hungerian is a bitch, a waste of time, and a real nuisance. But my experiences tell me that 100% OO projects on a prototype level are rare. Very rare.
And yes, I agree that when dealing with objects, use OO inspired names without hints of type. I guess the $o{whatever} was a bit too fast; it was meant for the normal 'a few objects, a few types, a few hacks' more than 'good clean prototypes.'
Thanks for the input. Point well taken. :)