Why Use JSLint?

In my social contract, I taked about using JSLint.

There were two problems reported with the current release of Operator that were very strange when I heard about them. One was that Firefox didn’t honor the “Show the tab bar when only one tab is open” preference anymore and the other was that external links opened in new windows. I spent a bit of time debugging the problem and tracked it down to this code:

  disable: function()
  {
    toolbar = document.getElementById("operator-toolbar");
    toolbarbuttons = toolbar.getElementsByTagName("toolbarbutton")
    for(var i=toolbarbuttons.length - 1; i>=0; i--) {
      if (toolbarbuttons[i].id != "operator-options") {
        toolbarbuttons[i].setAttribute("disabled", "true");
        toolbarbuttons[i].label = toolbarbuttons[i].getAttribute("origlabel");
        toolbarbuttons[i].setAttribute("label", toolbarbuttons[i].label);
      }
    }
  },

Do you see the problem there? Because I didn’t have “var” in front of toolbar, I was affecting the global variable toolbar which was causing all the problems that people were seeing. Anytime an extension uses a variable with a common name without putting “var” in front of it, it risks overwriting other global variables in the browser.

Running JSLint through my code with the “Detect undefined variables” option would have found this problem and other problems as well. When I used JSLint, I found many cases where I had done this and I was able to easily find and fix them all.

Some of the other things I was able to fix as a result of JSLint included missing semicolons, unnecessary global variables, using == where I should use ===, as well as general cleanup. One error in particular (Weird construction. Delete ‘new’.) encouraged me to reevaluate some code I had written and I was able to clean it up considerably.

So I would encourage you to at least attempt to run JSLint against your extension to make sure you aren’t creating any side effects you don’t intend.

Note that there is one construct that JSLint complains about that is very common in Mozillla/Firefox source code:

Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
                           .getService(Components.interfaces.nsIPromptService);

JSLint would prefer you wrote it like this (note the location of the period)

Components.classes["@mozilla.org/embedcomp/prompt-service;1"].
                            getService(Components.interfaces.nsIPromptService);

I went ahead and made this change in my code to avoid seeing the JSLint errors, but your mileage may very.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

7 thoughts on “Why Use JSLint?

  1. JSLint checks for the coding styles to match with Douglas Crockford’s guide [http://javascript.crockford.com/code.html] and hence you should break after an operator 😉 Also, I believe it reports a warning when using ++.

    That said aside, its always better to declare variables (using the var keyword) at the start of the function since JavaScript has function scope, which would emphasize this.

    I would prefer:

    function f() {
    var i, // some more vars

    // …
    for (i = 0; // …)
    // …
    }

    instead of:

    function f() {
    // …
    for (var i = 0; // …)
    // …
    }

  2. using == where I should use ===
    Hm, I didn’t realize javascript had that operator. How does it know when a lazy comparison is bad though?

    Do you see the problem there? Because I didn’t have “var” in front of toolbar, I was affecting the global variable toolbar

    I should really look into this because I had the same kind of problem, but it only caused negative side effects in msie *and* it was in Prototype’s try{} block which discards exceptions. Hooray. I blame my undergraduate CS education for not teaching me about lint … or version control, or MVC, or relational databases or…

  3. Michael, I always run Firefox with javascript.options.strict switched on. It catches undeclared variables and some other common mistakes (like mistyping a property name which causes “reference to undefined property” warnings). I tried JSLint but some parts of the enforced syntax are pretty ridiculous – like mandatory block parentheses and using === instead of ==. Most warning types cannot be disabled which causes lots of noise, so JSLint is pretty useless for me right now. And I really can’t see the added value if compared to Gecko’s own warnings.

  4. Is there any use case which makes the comparison operator == meaningful? I’ve always wondered why such an operator exists. Automatic type conversion makes me crazy when debugging.