I was recently playing around with labels and blocks (as one does) and found that they could be used as a way to annotate/contain chunks of JavaScript without using ugly comments (or abstraction?). I can see its appeal – it offers a sense of containment that is hard to get with just comments.
I’ll use the example of a really simple “getJSONP” function:
// BEFORE function getJSONP(url, success) { var ud = '_' + +new Date, script = document.createElement('script'), head = document.head || document.getElementsByTagName('head')[0] || document.documentElement; window[ud] = function(data) { head.removeChild(script); delete window[ud]; success && success(data); }; script.src = url.replace('callback=?', 'callback=' + ud); head.appendChild(script); } // AFTER function getJSONP(url, success) { declareVars: { var ud = '_' + +new Date, script = document.createElement('script'), head = document.head || document.getElementsByTagName('head')[0] || document.documentElement; } defineCallback: { window[ud] = function(data) { head.removeChild(script); delete window[ud]; success && success(data); }; } addScriptToDocument: { script.src = url.replace('callback=?', 'callback=' + ud); head.appendChild(script); } } |
You may think that doing this borders on totally pointless and in this instance I’d probably agree, but you must admit it could potentially be useful in other situations (none come to mind though).
We’re normally used to {
and }
being used to delimit an object literal, but they can also be used to create blocks (or “compound statements”). A compound statement is a statement that contains any number of sub-statements. We use them all the time:
while (true) normalStatement; while (true) { iAmInACompoundStatement; soAmI; ermICallItABlock; } |
We use them everywhere, if
statements, for
statements, while
statements, switch
statements, try/catch
statements …
Since JavaScript doesn’t have block scope, using a block anywhere other than in the conventional places (if/while etc.) is almost totally pointless. However, as I mentioned, we could use them to annotate and contain logically related pieces of code:
definingMyVar: var x = 123; definingABunchOfVars: { var x = 123, y = 456, z = 789; } |
We can even use break
within these blocks:
var x = 1; foo: { x = 2; break foo; x = 3; } x === 2; |
Note that the break
statement must include a label, otherwise it’s invalid; unlabelled break
/continue
statements are only permissible within switch statements and loops.
I dare say this is all quite pointless… but very interesting nonetheless. What say you?
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
They do improve readability, but it would suck ball to minify it
Interesting, but I think I’ll stick with comments.
I actually prefer the look of languages that avoid the need for curly braces altogether, like Python.
for a less advanced programmer this could also, in some cases, lead to helpful hints of where to refactor. The labeled blocks could, ultimately be extracted into reusable functions.
Definitely looks like a handy little tip to have at our disposal, thanks for sharing that! You can never have too many control structures, I always say.
I found a quick reference guide while Googling for more info:
http://snipplr.com/view/8255/javascript-labels/
Douglas Crockford doesn’t think too highly of the labels though, for some reason (he doesn’t get into much detail here):
http://javascript.crockford.com/code.html#compound%20statements
Here’s a question though: Can the label be referenced or used in any way programmically, or is it strictly a visual reference?
@V1, good point, although I don’t think how-we-code should be affected by how-it-will-compress.
@Pete, I tend to prefer curly braces AND white-space as opposed to just white-space. Although I guess I’ve been conditioned quite a bit by all of these C-style langs.
@David, another good point! I can see it being useful as a general form of annotation although comments may be better in some instances.
@JGarrido, Labels are programatically useful only when you use the continue or break statement to exit a block or continue a loop (for/while/do):
AFAIK, there’s no other way to use labels.
Good idea! In some cases it can help to classify the codes.
Interesting idea, but I think this actually decreases code readability. Using labels and blocks in that manner gives them the impression of being name / properties of an object literal, at first glance anyways.
Just wait until they implement goto. Then these will be very much useful! 😉
This is fun!
In some projects, there is quite a big operation on the same level of nesting in code. Then help conditional comments, but not so good.
I Experiment with blocks!