Posts tagged "javascript"

JavaScript Puzzlers @ VanJS

At Adobe MAX this year, I presented the first in a series of presentations that I call “Puzzlers“. Inspired by Joshua Bloch’s Java Puzzlers, my talk presented some peculiar, and sometimes seemingly wrong, behavior in the JavaScript programming language, all demonstrated through the use of clever puzzles! Anyways, the talk had some great feedback, and started some fantastic discussions, and so I thought I should keep going. I most recently finished presenting a variation of this talk to the fine folks at the Vancouver JavaScript Developer Group, VanJS. Below is the video…

Thanks to the awesome folks at VanJS for having me!


JavaScript Puzzlers – Puzzles That Make You Think (presented at Adobe MAX 2013)

I’ve just recently returned from Adobe MAX 2013, Adobe’s annual “Creativity Conference”.  I had the opportunity to host a session this year.  I ended up doing a presentation called “JavaScript Puzzlers”.  In short, my presentation presents the audience with short, code-based “puzzles” which the audience then has to solve.  The puzzles themselves are quite simple, anywhere from 2 to 20 lines of code.  The answers, however, more often than not, can be quite surprising.  Well, the video from the presentation has finally gone online and so here it is…

I’ve also made the full set of slides available here…

We had a great turnout, and some fantastic discussions!  Thanks to everyone who was able to attend!  I had a blast!




Javascript Puzzlers at Adobe MAX 2013!

Adobe MAX 2013 Banner

Come one, come all! Adobe MAX 2013 is just around the corner! For those of you attending, I’ll be presenting a session on the last day based on my “Puzzler” series! The session will be geared towards Javascript developers, particularly, helping you identify quirky behaviour and subtle nuances of the language. The goal of this presentation will be to give you some extra understanding around these scenarios to hopefully help you write better code, all presented in a series of fun “puzzles” :) The session is called “Javascript Puzzlers”, and here are the details…

What: JavaScript Puzzlers: Puzzles to Make You Think (and write fewer bugs)
When: Wednesday, May 8th from 3:30PM – 4:30PM
Where: Los Angeles Convention Center, Room 504, 1201 South Figueroa Street, Los Angeles, CA
Why: Because Javascript can be tricky!

For those of you who aren’t attending, that’s okay! You can register here to watch the keynotes and select featured sessions online live and for free!

Register to view keynotes online for FREE!

Finally, for those who are interested in registering to attend in person, there are still spots available! Register here!

Register to attend Adobe MAX 2013!

Hope to see you there!


JavaScript Puzzler – Let’s Print Some ZIP-Codes!

Let’s take a look at a JavaScript Puzzler. If you don’t know what a Puzzler is, it is essentially a short problem used to demonstrate a quirk or edge-case with the language that you might encounter. Here is the format:

  1. Code – I introduce the code
  2. Question – I pose a multiple-choice question and you guess what the outcome is…think hard!
  3. Walkthrough – I walk through a reasonable explanation
  4. Answer – I tell you the real outcome (it might surprise you), and explain why
  5. Moral – How can we avoid making mistakes like this in our own code

Now that we all know what a Puzzler is, here is a simple JavaScript Puzzler:


<script type="text/javascript">
	// array of 6 valid zip-codes
	var zipCodes = new Array("93021", "16284", "02392", "20341", "08163", "32959");
	// let's do something with each zip-code - for now, print them out
	for (i = 0; i < zipCodes.length; i++) {
		// sanity check
		if (!isNaN(parseInt(zipCodes[i])) && parseInt(zipCodes[i]) > 0) {
			document.write(parseInt(zipCodes[i]) + " ");


What does this print?

  1. 93021 16284 2392 20341 32959
  2. 93021 16284 2392 20341 8163 32959
  3. 93021 16284 20341 32959
  4. none of the above


So, we have an array of 6 ZIP-codes in string format. We iterate through each one and print it, but first we do a sanity check. Let’s walk through each number and see if it passes.

  • 93021 – This will return a number and it will be greater than 0, so “93021” will be written.
  • 16284 – This will return a number and it will be greater than 0, so “16284” will be written.
  • 02392- This number has a leading 0, but parseInt() will just trim it. So, this will also return a number greater than 0, and “2392” will also be printed (Note: no leading 0).
  • 20341 – This will return a number and it will be greater than 0, so “20341” will be written.
  • 08163 – The same as the other number with a leading 0, parseInt() will trim this and return valid number, so “8163” will be printed (Note again: no leading 0).
  • 32959 – This will return a number and it will be greater than 0, so “32959” will be written.

Therefore, we should see all six numbers printed, with the numbers that have trailing 0’s being trimmed. So, my answer is b, this code will print the string “93021 16284 2392 20341 8163 32959”.



















If you chose a, you were close. The answer is actually d – none of the above. This is because the ECMAScript standard does not define the interpretation of certain number literals, in particular number literals with a leading 0. Some JavaScript implementations will interpret these as integers with the leading 0 trimmed. Others will treat them as octal literals. It should be noted, though, that MOST JavaScript interpreters will perform the latter and interpret number literals with leading 0’s as octal literals. This is different from other languages, like Java’s Integer.parseInt(), which will conversely trim the leading 0.

So what actually gets printed? In most browsers, including IE 8, Firefox 3 and Chrome, the string “93021 16284 19 20341 32959″ gets printed (Notice the 19!). Let’s examine this step-by-step one more time…

  • 93021 – There is no leading 0, and so this number will get interpreted just as we expect, as the integer 93021, and so “93021” will be written.
  • 16284 – Again, no leading 0, so no surprises here. “16284” will be written.
  • 02392- This number has a leading 0, and so it will be interpreted as an octal literal. Notice, though, that the second least-significant-digit is a 9, which is not allowed in an octal number! And so, by the specification of parseInt(), it will read all digits until an illegal character is read. Therefore, parseInt() will parse the octal value 23, which equals ((2 x 8) + (3 * 1)) = (16 + 3) = 19 in decimal.
  • 20341 – This will return a number and it will be greater than 0, so “20341” will be written.
  • 08163 – Again, this number has a leading 0. But, this time, the most-significant-digit is an 8, which is also not allowed in an octal number. So, parseInt() will interpret the octal value 0, and return 0. This fails the second part of our sanity check (that our ZIP-code must be non-zero), and so this doesn’t get printed!
  • 32959 – This will get printed as is. No surprise here either.


Whenever possible, do not write an integer with a leading zero. Doing so can cause unexpected behaviour across browsers with different JavaScript implementations. If you can’t control the input values (as in our example above), then make use of parseInt()’s second optional parameter, radix – e.g. use parseInt(“08163”, 10) to parse “08163” to a base-10 integer. Passing in the radix explicitly eliminates the variability between browser implementations.

That’s it for this JavaScript Puzzler! Until next time, happy coding!

Charles (source code)