James Shore

Lessons Learned: Lint and Javascript

Wed, 16 May 2012 00:00:00 PST

16 May 2012

James Shore/Blog

Yesterday, I announced my new screencast series, Let's Code: Test-Driven Javascript. Today, I'm pleased to share an early screen test for the "Lessons Learned" channel. The goal for this channel is to provide a distilled look at a specific topic—to provide maximum information in minimum time. The series also includes "Live" and "Caffeinated" channels: a live recording of a real-world web application as it's developed, similar to my popular Let's Play TDD series. For details, check out the Kickstarter!

Lessons Learned: Lint & Javascript

In this video, we take a concise look at what Lint is, how to use it, and how to incorporate it into your automated build. The example source code is available on GitHub and the transcript is below.

Transcript

Hi, everyone. This is James Shore with my lessons learned about Lint and Javascript. We're going to look at what linting is, how to use it, and how to incorporate it into your automated build.

What is "Lint"? `(00:10)`

Lint tools read your source code and look for common mistakes. In Javascript, this means things like missing semicolons or unsafe comparison operators. Javascript is full of "gotchas" that silently introduce bugs. A linter is invaluable for keeping your code defect-free.

The leading linter for Javascript is JSLint, by the famed Douglas Crockford. Now, Douglas Crockford can be a bit... curmudgeonly, and some people don't agree with some of the choices he's made with JSLint. They've forked JSLint to create JSHint. It provides more control over what's flagged as an error and what's not.

I chose to use JSHint for Let's Code: Test-Driven Javascript, but most of what I'm about to describe is equally applicable to JSLint.

Running JSHint Manually `(00:50)`

The easiest way to run JSHint is to go to the website, paste in your code, and hit the "Lint" button. That's fine for one-off scripts, but not really suitable for professional web development.

Another option is to use the Node package manager to install a copy of JSHint. (You'll need to install Node first, if you haven't already.) If you use the -g option when you install JSHint, it will put a convenient command-line interface on your path.

Automating JSHint `(01:13)`

Personally, I don't think the manual approach is a good idea. Javascript has so many gotchas that you really need to run Lint all the time, as part of your automated build. And if it's going to be in your automated build, you should install JSHint locally, not globally. That will ensure your build still works when other people check out your repository.

Once JSHint is installed, you can require() it in your build script. JSHint and JSLint both provide the same interface, and it's not a particularly friendly one. There's only one function exposed by the module: JSHINT. It takes the source code to check, a set of options, and an optional set of globals, and returns true or false depending on whether the lint succeeded or failed. It also populates an errors array on the JSHINT function with specific error messages.

Processing Files `(02:00)`

The first parameter is the source code. You'll need to load your files from the file system. To load a file, use the readFileSync() function in Node's fs module. readFileSync() reads an entire file into memory. It takes a file encoding; if you're not sure what to use, utf8 is usually a safe bet. Once you have the file, you can pass it to JSHint.

Your automated build will likely have a list of files to check, so you'll need a function that calls Lint for each file and collates the overall "pass / fail" status as it goes.

Options `(02:28)`

The second parameter is an object containing your JSHint options. These options control what Lint complains about and what it allows to pass. They're described in detail on the JSHint web site, so I won't repeat that here.

Globals `(02:41)`

The third parameter is optional. It's an object containing your global variables. If you set the undef option to true, then JSLint will complain if you use any variables that haven't been explicitly declared. This third parameter allows you to make exceptions to the rule. For each global variable name you include, you set it to true if your code is allowed to change the variable, or false if it isn't.

Per-File Settings `(03:02)`

You can also define options and globals by using a block comment at the top of a Javascript file or at the start of a function. This is useful for changing your global JSHint options on a case-by-case basis.

Interpreting JSHint's Results `(03:13)`

When you run JSHint, it returns true or false according to whether or not your code passed. That's enough to cause your build to fail when you need it to, but you'll also want to print out the details of what Lint found.

To do that, you'll want to examine JSHint's errors array. Some elements of the array are blank--you can just skip those. The rest are objects with three properties: line, which is the line number; evidence, which is the source code containing the problem; and reason, which is Lint's error message. Sometimes line and evidence are left out, so you'll want to check for that.

Conclusion `(03:46)`

So that's what I've learned so far about Lint and Javascript. To summarize, Lint is a tool for checking for problems in your source code. Given Javascript's "gotchas," I think it's an indispensable part of your automated build. You can use JSHint to include Lint in your build. Check out the source code for this episode for an example of how to do it. The link is available on your screen.

Thanks for watching, and I'll see you next time!

Back this project on Kickstarter! http://letscodejavascript.com

Comments

Announcing: Test-Driven Javascript Screencast

Tue, 15 May 2012 00:02:00 PST

15 May 2012

James Shore/Blog

It's alive! Let's Code: Test-Driven Javascript has been launched on Kickstarter.

Let's Code: Test-Driven Javascript is my new screencast series focusing on Javascript, TDD, Node.js, and professional web development. It's a response to the success of my Let's Play TDD series, which has grown to be truly massive--189 videos and 45 hours, at the time of this writing.

Where the original series focuses on Java and Swing, the new series focuses on Javascript and web technologies. Many people I meet don't bother testing the front-end logic in their web applications. But as web apps get more and more sophisticated, TDD and other rigorous development practices become more important. That's why I want to produce Let's Code: Test-Driven Javascript.

I'm launching the series through Kickstarter so I can give it the time and attention it deserves. My intention is to create an invaluable resource for anyone doing professional Javascript development. Back it on Kickstarter!