Sit back. Close your eyes. Imagine the scene.
Your client is sat round a big 3 inch thick mahogany table, in a tastefully decorated 1930’s art deco hotel conference room. They lean back in their reclining leather chairs whilst sipping chilled Harrods mineral water served in crystal wine glasses. The leather creaks. The sun pierces the cloud glinting through the gaps in the blinds filling the room with a coruscating light, a dazzlingly you are praying to match in the events that follow. Formalities are exchanged and weather is discussed. A thin veil of cultural formality gives you a brief respite from the reason you all know you are there.
You tap the mouse connected to the macbook. The projector flickers into life. The first page of your masterpiece is lit up. Each pixel a glorious testament to your craftsmanship and the pain, sweat and blood you’ve slaved over for the past iteration. Each click though the journey provides the perfect accompaniment to your commentary, going deep and deeper into your world, building a crescendo around it that signifies your masterful control of your media. Click follows click. Ouuu follows ahhh. And then…
Bang!
Has this or something along similar lines ever happened to you before?
Your heart sinks. Your face burns as the blood rushes like a stampede of elephants into your cheeks. You blush. You stutter a laugh. Make a self deprecating witticism about the realities of live demos. You click ok. You proceed with the demo. Inside you are crying tears of shame and remorse. “Why didn’t I catch that before?” you think.
Which, by the way, is wrong.
If you had more time to think about the question you should have actually asked is “why did that happen at all?”. To which the answer would have been, it shouldn’t.
Debug code, should never make it into the production environment. It’s just bad practice. Plain and simple. So the question becomes, “how do we stop it?”.
On my latest project I’ve been working with CI or Continuous Integration. I won’t go into the details of how CI works, you can find that out yourself.
As part of this, I’ve been using 3 very important tools: Maven, JSLint4Java and JSLint itself.
Maven is a build tool that allows me to add the marvellous JSLint4Java ant plugin to it. This means when Maven is triggered by the CI system, JSLint gets run on all the Javascript and CSS files in my project. If they fail the validation: the build fails. Simple as that.
Now, this gives us a lot power, to help both enforce code consistency, valid code and good code.
But up until recently, JSLint has not had the functionality to check for the javascript global alerts, consoles, debug or opera statements. But as of 19th of November 2009, after suggesting a console check, on the JSLint working group forum. The ability to be able to check for the globals: console, alert, Opera, prompt and debug have been added to JSLint by programming/Javascript legend Douglas Crockford himself.
AWESOME.
The new functionality comes under the ASSUME keyword, that when you switch off using the following code:
/*devel : false, debug : false */
will fail the file if any of those statements are present in the code…
This brings us one step closer to the holy grail of front end code RELIABILITY and eradicates the scenario I wrote about at the beginning of the post. But still doesn’t completely protect you from looking like an idiot in front of the client, so take care!
