Here’s a close facsimile of a tiny snippet of the javascript that it puked on. (I can’t paste the actual code since it doesn’t belong to me.)

Brackets and shoes required

JSLint’s main complaints were with the four if statements. As you can see, none of them have curly brackets ( { } ). My philosophy was that the { } make the code less readable and were only added to the javascript specs to help group multiple statements.

My background is heavily laden with pascal, and in pascal this is exactly the case. The if statement is defined as: if [conditions] then [statement]. (Note the singular [statement].) To group multiple statements, you need to use a grouping statement such as the begin statement which is declared as this: begin [statements...] end.

I was happily snubbing my nose at all those developers who thought there was some golden rule that brackets { } were stipulated.

Little did I know they were right!

I decide to check my javascript bible. It’s a copy of the javascript 1.5 specs I downloaded from Mozilla just after Netscape was bought by AOL. I refer to it now and then. Like when I can’t remember the order of the Array#splice parameters, or when I need to make sure my regex will run in all browsers.

Anyways, I decided to check the specs. I think it’s the first time I actually looked at the if statement. At least it’s the first time I really looked at it. And there it was in front of me: the specs mandate the use of the { }!!!

Syntax
if (condition) {
   statements1
}
[else {
   statements2
}]

It’s also obvious that the if (and else) blocks are grouping statements.

I’ve been totally foiled!

But I still think it’s more readable without the { } under some circumstances so I’ll probably continue to omit them when it feels right (and my client isn’t running my code through jslint). So there!

A perfect storm of anti-patterns

My next biggest trangression was with the following foible:

if (!already)
    var itemInit = ctrlr._getItemInit(which);
if (itemInit)
    // some lines snipped
    itemInit.call(ctrlr, root, doneMap);

The exact complaint was:

Problem at line 16 character 21: 'itemInit' used out of scope.

This is patently untrue. itemInit is definitely in scope. If you can’t see that, you’re either a dumbass noob or you’ve been blinded by java. In javascript, scope is determined by function blocks, not by statement blocks or any other type of block (except the with statement, but let’s not go there).

Therefore, this code is 100% legit. It doesn’t break in any javascript environment. Just because the var statement is in an if block, does not change the fact that it is in scope throughout the function block. It doesn’t matter where the variable is declared in the function: the scope of the variable is always the entire function.

In fact, the following code, despite being totally mental, will work flawlessly and won’t leak the today variable into the global scope as JSLint insists it will:

(function beerOfTheDay () {
    today = new Date();
    return 'Old Rasputin Imperial Stout ' + (today.getDay() == 5 ? 'is' : 'isn't') + ' the beer of the day.'
    var today;
})();

But does that make it right? Well….. no.

When I wrote the original code for my client, there was a perfect storm of anti-patterns that took over my psyche. (That’s my story and I’m sticking to it.)

The first anti-pattern:

This project is getting bulkier than I had planned. I better start conserving bytes. Placing the gimped var itemInit; outside the if block will add a whopping 9 bytes! Ouch! Every little bit counts!

The second anti-pattern (to help justify the first):

This is a core function. I better squeeze every last CPU cycle out of this. If I were to use var itemInit = !already && ctrlr._getItemInit(which);, the javascript interpreter is gonna have to write to the heap and that’s ssslllloooowwwww. bad. bad. bad!

The final (and kicker) anti-pattern:

This is pretty obvious. I mean, look. The var statement is sitting just above the lines in which the variable is used. Nobody with half a brain is gonna miss that!

The first two anti-patterns aren’t always anti-patterns. If you’re writing code for mobile devices, you may need to skimp on bytes just so your code can sneak into the device’s cache (ahem, iPhone). Or if you’re writing code that may need to execute hundreds of times per second, avoiding a variable assignment might be a good thing.

Of course, neither of these were the case here. (In my defense, I was working on a parallel project in which both of these were the case!)

The third anti-pattern is antithetical because code is always changing. Today it may look fine, but tomorrow — under somebody else’s gaze or after a few iterations of feature requests — it may look completely different.

This third anti-pattern is the one that bothered me the most. I strive to always write code that’s easy for another developer to understand and manipulate. This, clearly, was a minor transgression and I’ll need to refocus my efforts in this regard.

So, in one respect, JSLint helped me out today. But that doesn’t mean I like it any more than I did when I cursed at it earlier today. It’s still a stupid tool that doesn’t know shit about good code as far as I’m concerned.

For instance, don’t effin tell me to always use obj === null. Some times I really do want to use obj == null! I know the difference, and will likely leave a comment so the next noob who comes along doesn’t screw it up.

Stupid friggin tool.