Made of Everything You're Not

For most web developers that I’ve met and worked with, at least, the concept of “hard coding” variable values, especially environment variables, is a definite “I will kill you and your first born if you do this” offense. Through a combination of painful moments, especially in the push to live phase, we all learned just how fucked up hard coding could make a day.

Portability Is A Good Goal

I’m telling you, it’s a special kind of pain when you’re frantically trying to fix a site you broke through poor planning and execution.

So, we do the most logical thing and abstract out all the system variables into a single point; either a config file or a database usually. For some reason we then go about our task feeling proud that we’ve stopped hard coding, oblivious to the fact that all we’ve done is just minimized the amount of hard coding. And that’s not enough.

According to WikiPedia hard coding

…refers to the software development practice of embedding input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

Now, while that explanation is appropriate for good old fashioned native development, to be sure, I don’t think it’s applicable to web development because for most sites the database is as much a part of the application as the code is (especially when doing maintenance work). By which I mean that, in my experience, storing environment values inside a database isn’t a good idea unless there’s no other way (sometimes a project requires the rules be broken).

Anywho, for most of us who don’t have the natural, innate, knowledge, learning not to hard code was a tough lesson because when we first started developing web sites it was natural to connect the idea of the web site with the code and server it was running on. Hell, I personally remember being shocked to find out it was actually bad to develop a site on the live/production server; just didn’t make sense at the time (stupid, I know). In hindsight it was an obviously silly and short sighted mindset to adopt but changing that was probably the most important choice I’ve made to improve the quality of my projects.

I was reminded of this with painful clarity when a whole slew of issues came up from a client I’m working with. During the course of transitioning dozens of their legacy sites to a new server, some of which hadn’t been updated since the projects were completed some years ago by coders long since forgotten, quite a few started having weird and, not a little insidious, bugs in the new environment. Looking deeper into the issues revealed a nasty amount of hard coding in not only the custom projects, which I would expect actually, but also from various third party commercial and open source projects that were used for the base of the sites.

Here’s an example of what I’m talking about in terms of your everyday configuration file hard coding along with an example of what I’ve learned to do:

<?php
//bad
$path = '/var/www/mysite.com/html/';
$url = 'http://www.mysite.com';
$cache = '/var/www/mysite.com/cache/';
 
//good
$path = $_SERVER['DOCUMENT_ROOT'];
$url = 'http://'.$_SERVER['HTTP_HOST'];
$cache = $url.'/../cache/';
?>

All thanks to the $_SERVER variable, in PHP (though most languages have some way to get that info), you shouldn’t have to ever hard code the paths to pretty much anything within your site. Note though that when executing PHP through CLI scripts or using the exec() function all bets are off (though there are ways to get around that too like using variations on __FILE__ and dirname()). And, yes, there are circumstances that demand hard coding, I know, but those cases are few and far between and usually have people capable of making those changes.

It was the third party programs that really annoyed me though. I find it a little easier to accept an individual inexperienced coder’s exuberance in coming up with a base solution at zero hour. I’ve been there; an issue comes up and the quickest, and less painful, solution is to just throw the path in place with a perosnal promise to come back later and make it elegant. Then… well, life takes over and the promise is forgotten. Happens all the time.

On the other hand though, when dealing with third party projects, both open source and commercial, this type of hard coding, well, that just bugs the crap out of me. It seems like such an obvious design decision yet Expression Engine, Zen Cart and WordPress (for example) all hard code environment variables into the configuration files.

This is especially irritating to me because it’s been my experience that most websites move to a different server at one time or another, so it’s a given that configuration is going to be changed at some point. Keeping the pain of moving the site to a minimum rates a higher priority to me. And, unless I’m missing something, it seems that there’s very little difference between having your installation/configuration script write $_SERVER['DOCUMENT_ROOT'] versus “/var/www/html” to a configuration file.

Something like (as a base example with no sanitization):

<?php
if($_POST['path'] == $_SERVER['DOCUMENT_ROOT'])
{
    $path = '$_SERVER[\'DOCUMENT_ROOT\']';
}
else
{
    $path = $_POST['path'];
}
 
//write it to the config file
?>

As I mentioned above there are definitely times when $_SERVER['DOCUMENT_ROOT'] isn’t appropriate per the requirements or spec but for most projects that I’ve worked with replacing hard paths with the variable has been effective 99% of the time.

Related Posts

Tags: php, program design

This entry was written by Eric Lamb and posted on Tuesday, July 27th, 2010 at 12:00 am and is filed under Brain Dump, Code, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.