Defensive coding in JavaScript with Namespacing

daipratt — Fri, 02 Oct 2009 10:05:42 +0000

Having learnt some harsh lessons early on in my career about the drawbacks of using generic/common function names, such as init or basket for instance – I once took out important “add to basket” functionality on a major retail website due to a conflicting function name that only manifested itself in production. Not good.

Since then, I have embraced JavaScripts namespacing ability (along with anonymous functions) to complement the defensive style that I quickly felt the need to adopt! I think that coding defensively is especially important because it is often impossible to conceive what the future business requirements of a site will be, what client side code could be thrown at it, or the caliber of developer working on it. The last thing you want is a developer from the marketing department innocuously dropping a “cool” image rotating script site wide in the document and taking out business critical code as a result. It’s embarrassing for the guilty developer, but I think more so for the senior guy who should’ve coded more defensively in the first place.

This may or may not work for you, but I namespace everything to mitigate the chances of collision of functions, variables, objects, anything bar the root global variable name, from any new code that follows later, or more broadly OPC.

Anyway, a namespace essentially provides a container for all of your code to sit within. At its simplest, it can be defined like so:

var myFirstNamespace = {};

This can then be extended in any manner you please. For example:

//Extend myFirstNamespace
myFirstNamespace.helloWorld= function() {
	console.log('Hello World!');
};
 
//Use the myFirstNamespace properties
myFirstNamespace.helloWorld();

This would then write the following into your Fire Bug console:

Hello World!

Easy peasy.

As a real world example, at Bounty, everything new went into a bounty namespace, which in turn had things like bounty.utils, bounty.ui to separate the various functions that were held within. Here’s a skeleton namespace that might make it easier to understand what I mean:

var bounty = {
	init : function(){
		//Initialise functions within the bounty namespace
		bounty.advert.fInit();
		bounty.ui.fInit();
		bounty.utils.fInit();
	},
	advert : {
		fInit : function(){
			//Initialise bounty.advert
		},
		fAdvertFunction1: function(){
			//An advert function
		},
		fAdvertFunction2: function(){
			//Another advert function
		}
	},
	ui : {
		fInit : function(){
			//Initialise bounty.ui
		},
		tabBox : {
			fInit : function(){
				//Initialise bounty.ui.tabBox
			}
		}
	},
	utils : {
		fInit : function(){
			//Initialise bounty.utils
		}
	}
};
$(document).ready(function(){
	//Initiliase bounty.
	bounty.init();
});

I find that this style of coding helps in enforcing a structure to the code, which is particularly helpful when there are large quantities of it, and when it comes to debugging. Another positive side effect is that if your chosen code editor supports code folding, then you can quickly collapse everything and get a very clear architectural overview of what it does without having to trace your way through functions to understand what’s going on.

David Pratt » namespacing

Defensive coding in JavaScript with Namespacing