Trailing commas and unfeasibly high line numbers

Tuesday, July 8, 2008 - 13:04

In Javascript, trailing commas are to be considered harmful. Strictly speaking, they're not allowed by the syntax, but this wouldn't be such a problem were it not for the fact that some browsers (including Firefox) will quietly ignore them, pretending briefly that Javascript's syntax is Pythonic or, um, Rubric. The safest route to take is to avoid trailing commas wherever possible. I've mentioned the general problem before, and the hard core among you would probably go so far as to change their formatting to highlight trailing commas.

But what makes it all far, far worse is that IE6 and IE7 can sometimes produce error messages which, as is usual for those browsers, contain no useful information whatsoever.

Here's a recent example:

Line: 64432871
Char: 2
Error: Expected identifier, string or number

See that impossibly high line number? That's a result of the parser being struck soundly on the head by the syntax error, and consequently dribbling its way past the end of the Javascript file. IE's incomprehensible "English" error message conspires with circumstance to make the whole report of no help at all.

Something like JSLint, on the other hand, is of tremendous help, and we'll be running as much Javascript through it as possible in future. JSLint is just as unforgiving, but as it's reliably unforgiving and incredibly communicative with it then that's a bonus rather than a detriment.

It's sometimes a little too strict to be useful, complaining about implicit global variables (even when that variable is called window). My suggestion is to ignore those reports, though; but watch those commas!

Comments

Ben Werdmuller (not verified)

Tue, 08/07/2008 - 18:31

I hate Javascript errors in IE, almost as much as Javascript itself ...

The problem with JSLint etc is that we often do dynamic js generation, where pasting it in probably isn't going to cut it. The debuggers by and large don't seem to really have caught up with ajaxy stuff (we're into jQuery), although you can at least get something vaguely descriptive with Firefox. Opera Dragonfly looks like it might be alright too.

jps (not verified)

Mon, 14/07/2008 - 12:55

I've grown to quite like "proper" Javascript, whatever that means.

When it first came out I used to hate it more than almost anyone else I knew, and decried it as a tool for crashing browsers with. Now it's matured and can actually be really interesting to play with, as single-threaded event-driven asynchronous programming environments are rare, and nothing can give the feedback that Javascript can. jQuery's ace too: it adds that little extra sprinkle of functional programming while removing most of the crashingly boring OO DOM stuff.

We actually moved away from dynamic JS generation, as it was a bit flaky, and quite hard to debug as you suggest. Instead we tend to use static Javascript with dynamic JSON to drive it.

Piers Cawley (not verified)

Fri, 29/08/2008 - 23:39

One of the principles of good library design in Perl was/is that, although Perl allows for dynamic code generation with eval STRING, you do everything in your power to avoid using it. This principle arose as the result of bitter experience.

In a language with closures and dynamic dispatch, it's amazing what you can achieve before you have to resort to dynamic code generation (about the only place where I'd say it's legitimate is when a section of code is painfully slow as a result of indirection, can be massively sped up through code generation/compilation and is a 'hot' part of the code. I can count the occasions when I've needed to do this on the fingers of one hand, if that.)

Javascript has pretty much the same feature set when it comes to avoding code generation, which can only be a good thing.

jps (not verified)

Sun, 31/08/2008 - 18:04

Ah, of course. I tend to forget that Javascript even has dynamic code generation: I almost feel like, why would you bother? It's such a maintenance headache, and you can almost always avoid it outside of deep-framework calls.

That would also explain why closures provide the perfect alternative to giving e.g. setTimeout a string of text to evaluate.