JavaScript is a great language. It really can power your entire web stack from animated effects on the frontend to ajax calls for faster user experiences, to backend JSON APIs written in NodeJS. It’s been called the language of the web before, and never has it been more true than now.
I’d like to share some little techniques I’ve picked up which make your life easier as a professional JavaScript developer. Actually the first two are applicable to many languages.
1) One line debugging
Console.log is much better than alert debugging, but not as good as actually using a debugger. But we all still use console.log from time to time. Using console.log does have one drawback – if the console is not available then the program crashes. So you have to go through and manually comment or remove all your console.logs, or you have to have a wrapper debug function like this:
and when you’re done debugging just comment out the console.log inside the function.
The first is just a huge waste of time and is prone to mistakes. The second approach I’m not a fan of for a number of reasons: firstly when you’re not debugging you’re still calling the function all of over place pointlessly. Secondly you either need to include a complicated debug function, or you’re limited to just using console.log, and with only one argument.
My solution:
This way you can just change the first line to set the debug variable to false and none of your console.logs will execute. You retain flexibility in that you can put anything after the “debug && ” part, you’re not restricted to using console.log for your debugging; so if you really want, you can say debug && alert(‘important debug message’). Also it’s more lightweight code-wise, you don’t have to write your debug function every time you want to use it, just that very simple “var debug = true;” line at the top of your file, which also makes it clear whether debugging is on or off.
It makes debug lines really obvious, and my eyes have very quickly learned to skip over the debug lines when I’m reading the code, because it’s immediately clear that this is debug;
Because of lazy evaluation, it means cycles aren’t wasted parsing the arguments and sending them to the function; if debug==false then the interpreter will just skip the line straight away after parsing the boolean (this leans towards being a micro-optimisation and I understand if you take issue with it. It’s not the foundation of my argument for using these debug expressions, it’s just a nice-to-have).
It also makes it more likely you’ll keep your debug messages in the code instead of deleting them when you’re done debugging, which means that next time you need to debug the function, it’s just a matter of turning debug on and you’re ready to start tracing what’s happening (this is perhaps more useful in NodeJS as I’m unsure if keeping debug messages in client-side JS is a bad idea or not).
‘debug’ is not a reserved word in JavaScript, so it’s fine to use, but the “debug && someCall();” style of expression does not pass JSLint and I would not encourage this pattern in any other context (eg saying something like “options.wantsPingback && pingBack();” is not something I’d encourage – wrap it in an “if” for clarity). But for the special case of toggling debug messages I am happy with it.
2) Toggle comments
Speaking of toggling, sometimes you have a block of code you want to switch on and off frequently during development. It takes time to add “/*” at the top then find the end of the block you want to comment and add “*/”, and then remove it all when you’re done (and repeat the process to re-comment and so on).
Here’s a very neat pattern which da404lewzer on reddit calls “toggle comments”:
With the addition or removal of just one character at the top of the block, you can deactivate / reactivate a multi-line block of code. It’s very handy. I picked up this particular way of doing it from FionaSarah on reddit.
The only drawback is if the block itself contains multi-line comments, but in practice I don’t find this too much of a problem.
3) Revealing Module Pattern
When you are in complete control of all your code, you can ensure that all your functions are uniquely named. But when you’re using a bunch of libraries, how can you be sure that when you write a function called increment() that you’re not overwriting an ‘increment’ function of some other library you’ve used, thus breaking things in unexpected places?
By using the revealing module pattern, that’s how! It’s a very powerful way of using closure to encapsulate your code from the global namespace and provide a public API to your own libraries. I use it everywhere just out of habit now, and you should too!
Here’s a rough template to get you started. A full explanation is beyond the scope of this post but there are lots of good resources on the revealing module pattern if you google around.
The construction basically allows you to seal off your methods from outside access and ‘reveal’ those parts you want to be public. There are a few other ways of sealing code (eg the standard module pattern) but these have a variety of drawbacks which the revealing module pattern does not suffer from.
Recent Comments