Blue Onion Software

JSLint is a JavaScript program that looks for problems in JavaScript programs. It is a code quality tool.

JavaScript is a sloppy language, but inside it there is an elegant, better language. JSLint helps you to program in that better language and to avoid most of the slop.

I use this tool whenever I write JavaScript. It finds all sorts problems, many of which can be difficult to spot at runtime. My only gripe is that I have to copy the code from my Visual Studio editor to the Web site and then pick through errors.

There’s a plug-in for VS 2008 that integrates well with Visual Studio, but does not work with Visual Studio 2010. The plug-in model has changed in Visual Studio 2010.

I started writing a Visual Studio 2010 plug-in but soon lost interest. The Visual Studio object model is damn near inscrutable in my opinion.

Next I looked at writing a Resharper plug-in. Again, too hard. The documentation is weak and the object model is complex.

I finally settled on writing an external tool. Press Ctrl+K, Ctrl+J and the output window will display a report about your code.

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
 
(10,22): Missing semicolon.
    var naughtyMike = 0
 
Globals:         String
                 $
                 Date
                 jQuery
                 isNaN
                 Math
                 APP
                 System
                 document
                 ActiveXObject
                 OAuth
                 setTimeout
                 clearTimeout
                 clearInterval
                 setInterval
                 window
                 
Implied globals: badMike (5)
                 
Unused:          naughtyMike (9)

Not as cool as a plug-in but good enough for my purposes.

How it Works

JSLint is itself written in JavaScript. You can get the source at http://jslint.com/fulljslint.js. There’s also a nice little WScript wrapper for invoking and displaying the results at http://jslint.com/wsh.js.

I hacked these two files together into a file called JSlint.js. With this file in hand, I can now invoke the JSLint program from the command line as follows:

cscript c:\users\mike\bin\jslint.js < %1

“cscript.exe” is windows console mode script runner that ships with windows. It can run JavaScript and VBScript programs.

Here’s the JavaScript code that invokes the JSLint program and streams the input and output.

(function () {
    var i, e, data;
    if (!JSLINT(WScript.StdIn.ReadAll(), {passfail: false})) {
      for (i = 0; i < JSLINT.errors.length; i += 1)
      {
        e = JSLINT.errors[i];
        WScript.StdErr.WriteLine('(' + e.line + ',' + e.character + '): ' + e.reason);
        WScript.StdErr.WriteLine('    ' + (e.evidence || '').replace(/^\s*(\S*(\s+\S+)*)\s*$/, "$1"));
        WScript.StdErr.WriteLine();
      }
    }
    var show = function (title, array) {
      WScript.StdErr.WriteLine();
      WScript.StdErr.Write(title);
      if (array === undefined) { return; }
      for (i = 0 ; i < array.length; i += 1) {
        e = array[i];
        WScript.StdErr.WriteLine( (e.line) ? (e.name + ' (' + e.line + ')') : e);
        WScript.StdErr.Write('                 ');
      }
    };
    data = JSLINT.data();
    show("Globals:         ", data.globals);
    show("Implied globals: ", data.implieds);
    show("Unused:          ", data.unused);
    WScript.Quit(1);
}());

This is a modified version of http://jslint.com/wsh.js that pretty prints the JSLint results.

Integration with Visual Studio

To integrate this tool with Visual Studio you’ll need an additional file called JSLint.bat.

cscript c:\users\mike\bin\jslint.js < %1

You’ll have to modify the path to the jslint.js file.

Next, open “External Tools…” dialog in Visual Studio and add a new tool called JSLint. The specific command path will be different on your machine.

Finally, record a macro to run your new JSLint external tool command. Save it and assign it to a key combo (I like Ctrl+K, Ctrl+J).

Available on the downloads page.

I’ve been reading (and rereading) Douglas Crockford’s, “JavaScript, The Good Parts”. The style is simple and quietly disarming. The content is excellent. If I could make it required reading at my day job, I would.

One of my pet-peeves at work is that we don’t know how to say “No” to a customer or a bad idea. I’ve found it difficult to convince others. Crockford handles the issue head on and in only 5 paragraphs.

We see a lot of feature-driven product design in which the cost of features in not properly accounted. Features have a negative value to consumers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which is becoming negligible, but in mobile applications is becoming more significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.

Features have a documentation cost. Every feature adds pages to the manual, increasing training costs. Features that offer value to a minority of users impose a cost on all users. So, in designing products and programming languages, we want to get the core features --- the good parts --- right because that is where we create most of the value.

We all find the good parts in products that we use. We value simplicity, and when simplicity isn’t offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.

It would be nice if products and programming languages were designed to have only good parts.

I almost never consciously think about design in the programs I write. At least not in the sense that others would call “design”. I mostly write what’s useful and if I have any doubts, I leave it out. That occasionally infuriates others but I pay no heed. If I’m wrong, the truth of the matter eventually prevails and I admit my error. More often than not though the “issue” just dies quietly and I’m left to work on the “good parts”.

In JavaScript, when you make a new object, you can select an object to use as a prototype for the new object. This is “Prototypal Inheritance”, and it’s one of the key features that makes JavaScript different than classical inheritance languages like Java and C#.  It also has a serious deficiency that we’ll get to in a moment.

Typically, you define a constructor and augment its prototype. Borrowing an example from Douglas Crockford’s book, “JavaScript, the Good Parts”, we create a Mammal object as follows:

var Mammal = function (name) {
  this.name = name;
};

Mammal.prototype.say_name = function () {
  return "My name is " + this.name;
};

var mammal = new Mammal("Rhino");
mammal.say_name();

There are better and easier ways to create objects in JavaScript, but you’ll see this pattern often because it is the language designed way of creating objects.

In general the use of “new” is not recommended by Crockford. The reason why is that if you forget to use “new” when creating mammal, you’ll end up modifying the global object (this will point to the browser’s global window object). This accidental (and often fatal) modification of the global object is the main reason Crockford does not recommend using “new”.

Fortunately, there’s an easy fix to keep from accidentally misusing the constructor.

var Mammal = function (name) {
  if (this === window) { throw Error(); }
  this.name = name;
};

Mammal.prototype.say_name = function () {
  return "My name is " + this.name;
};

var mammal = new Mammal("Rhino");
mammal.say_name();

The underlined code prevents calling the constructor in the context of the global object.

Time for another tweetz update. Version 2.2 adds support for “Native Retweets”. What that means is tweetz uses the newer retweet support recently added to twitter. But fear not, if you like the old school method, you can simply turn off the option.

Like the web page, you’ll see a small popup dialog asking if you want to retweet the selected message to your followers.

I’ve also been doing some code cleanup as of late. As I learn more about JavaScript I’m finding that there are more efficient and effective ways to express things.

Lately, I’ve been learning about functional constructors in JavaScript. It’s a much cleaner, lighter and more robust way to allocate new classes objects.

It’s weird but the more JavaScript I write, the less I like C#. The biggest obstacle I’ve found is me having to unlearn a few things. JavaScript has it warts, but so does every other language out there. It’s takes a bit of practice, but you can write some truly nice code in JavaScript.

Check out the JavaScript series by Douglas Crockford over at Yahoo. Even if you’re not all that interested in the language, you’ll enjoy the story and learn some really interesting stuff about where some of those weird conventions in computer science come from (ever wonder why 80 columns was adopted as a standard line length? Hint: The 1890 census!).

Available on the downloads page.