ASI Scanning Test Grounds

This is a test for ASI certification.

• You will be presented with eight snippets of JavaScript/Ecmascript.
• None of these scripts will contain semi-colons.
• All of them validate according to ECMAScript 5.

Your job is to add all the semi-colons where ASI would put them.

That means that no ASI should occur after you're done.

These are the three rules to Automatic Semi-colon Insertion (ASI):

1. When unable to parse the next token and the previous token was seperated by at least one line terminator
2. When the end of input is reached and the current script cannot be parsed as Ecmascript
3. When a closing curly brace (}) is encountered

There are a few cases where no ASI is applied, even when the rules above would apply:

1. The resulting semi-colon may not cause an empty statement
2. The resulting semi-colon may not become one of the two semi-colons of a for-header
3. When the next line starts with a regular expression

There are also a few hidden cases, which you'll have to discover on your own ;)

You can only insert semi-colons.

The script was hacked together quickly so del and backspace screw your cursor position (just don't make mistakes! ;)

The cursor position is also the reason this test fails in IE. It has a very annoyingly complex way of getting the cursor position.

Press the next button when you think you've finished.

Results and explanation are presented at the end. Good luck!

The test is supposed to prove the point that you can't predict ASI well enough to rely on it.

By Peter van der Zee, September 2010

Last message: none

Used semi's: 0

Semi's to spend: 10

Well well well, let's see how you've done.

You've used semi-colons. There were actual cases of ASI.

Out of those ASI's, you've caught !

This means you've missed ASI's and wasted semi-colons

Still think not using semi-colons is wise?

Spread this on Twitter

Here are the answers to the test. The red semi's are the result of ASI.

Test 1: 101

This was a simple test to test the basic rules presented to you at start. There were two traps though. Both had to do with the function expression. One comes right after the d of the function body. It's just a script, so it ends with a semi-colon. The other one is that there is NO ASI after a function declaration. The specification simply doesn't require them so there's no reason for ASI to act. Don't forget that ASI is applied at the end of the source as well!

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 2: Textbook

The first part really is an example right from the specification. ASI is applied after the 2 because of the curly and of course after the three.

The second I altered for the test but was also an example. The incremental operator is a so called "restricted production". A bit counter-intuitively this causes ASI before the operator, rather than after.

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 3: Never do this

Classical example of a return statement gone rogue. The ASI happens right after the return statement. Again, function declaration so no ASI after it.

In the for statement, the only ASI is after the second alert call. And of course ASI happens after regular expressions. Don't be eluded by the rules ;).

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 4: Calling you out

Ninja's should have been primed for bracket problems here. Of course the foo and bar calls were decoys. Nothing interesting happens there. The issue lies with the function inside the for-loop that acts as a local scope. There are parenthesis surrounding these. These cause ASI to fail because they are interpreted as the call to the result of the first foo() expression. So it's basically foo()(function(){...}).

Other than that no ASI happens after the for, the rest is "normal".

In the for-statement, the only ASI is after the second alert call. And of course ASI happens after regular expressions. Don't be eluded by the rules ;).

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 5: Just warming up

No hint this time. Not much to report either. I'm testing whether you can spot that the return statement doesn't apply ASI mid-way an expression.

And the last line should have been obvious as it was outlined in the rules, no ASI if the next line starts with a regular expression (the whole thing becomes a double divison).

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 6: Out of control

This one is mainly about break having the same problem as return and whether you'd figure out that a labeled statement still counts as a line terminator (and there fore ASI being applied).

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 7: Stack 'm up

About annoyingly stacked functions. Function expressions get a semi-colon while function declarations do not. Often the cramped curly and parenthesis obscure the fact that they are still terminated by a semi-colon.

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Test 8: Mister y

Did you spot the ASI in the while loop? Note that no ASI takes place right after the while loop. And the tilde (~) operator is unary so ASI is applied before it.

You used semi's. There were ASI's. You found . You wasted semi's and missed ASI's.

Want to test your own script for ASI? Check out my parser.

This test was made for fun. But it also tries to prove a point. Using semi-colons is a "best practice" when it comes down to group projects. I don't care what you do with your own projects. But as soon as you are working with other people on the same project, you can't assume they all have the same knowledge on the JS rules as you do. And I hope theses tests also prove that some constructs come so natural that even the best scripter could fall for an ASI trap. So always use semi-colons in your JavaScripts. And if you do this always you won't have to be annoyed by them when you are required to use them.

By Peter van der Zee, pvdz.ee, September 2010