/dev/weblog

PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.

The second: stop using global variables; I mean it.

If there's one thing that really gets under my skin, it's the use of the global variable scope to store all kinds of things that just shouldn't be there. I've seen everything from lengthy configuration settings to global arrays for event hooks (I'm looking at you, MediaWiki). There are several reasons using globals is a bad idea, but I'll point out two important ones.

First, it's a vulnerability. The problem is that variables in the global scope are just that: globally available to be read from and written to by every line of code. A great security risk comes into play when sensitive information like usernames and passwords are available to your entire application or can be easily overwritten. What happens when an important global variable containing an array is overwritten to be a string? Whoops! The whole application just broke.

Second, it's sloppy. Putting values in the global scope so they can be accessed by your functions is hackish and ugly. It leads to problems with maintenance and debugging. If you have 500 functions that access a single global variable, you have to edit every last reference to it if you ever refactor your code. Consider what happens when you want to embed one application within another and they both happen to reference a global variable with the same name: mass hysteria.

What should you do, you ask? Matthew Weier O'Phinney made some good suggestions in an entry about Embedding Applications. He says use static properties or singletons to store your globally available settings; both good ideas. Let's go over two examples I brought up earlier and how to fix them.

Configuration settings should be loaded from and accessed through a configuration class; Zend_Config, PEAR Config, Solar_Config, you name it. You can throw exceptions for attempting to access a setting that isn't there, or just return null if you wish, but no more PHP notices about unset variables or array keys. Prevent changes to these settings except by actually modifying the configuration file. Store your passwords in an encrypted form. Place the actual configuration file outside of the web root. Make an instance of your configuration class available statically in a registry or by calling a static method.

Event hooks should be managed by a class with methods to add or remove hooks. Throw exceptions for an invalid event name or an unusable callback reference. Better yet: design a plugin API that implements the Listener or Observer pattern. You don't want someone inserting an invalid hook that breaks an entire system.

So long story short: use PHP 5's static properties or static methods to make available system settings and stop using kludgy globals.