Do you validate your JavaScript code?

Writing about whether people validate their CSS, it made me wonder about how/if people ensure the quality of their JavaScript code.

When I wrote about validating CSS, some of the feedback was that if you validate/promote valid HTML, naturally you should validate your CSS. With that sentiment, I’d argue that it’s as, if not more, important to also validate your JavaScript code (if you don’t agree, skip to the question at the end of this post, and give me a reply to that).

Enter JSLint

In difference to HTML and CSS, W3C doesn’t offer any way to validate your JavaScript code. However, JavaScript Jedi Master Douglas Crockford, founder of JSON, JSMin and lots of other work in the JavaScript filed has created the JSLint – The JavaScript Verifier.

You can read more about it in the JSLint documentation, but briefly put, it’s a great tool for verifying the syntax as well as best practices in your JavaScript code. As Douglas himself usually puts it to people using it for the first time:

It will hurt your feelings

While he might be right in some cases, I must say that since I started using it, my JavaScript code has gotten a lot better and I’m able to avoid both plain syntax errors as well as runtime caveats that many of us stumble onto way too often.

JSLint settings

When you first enter the JSLint validation page, there are a few checkboxes to check in the Options box I’d like to recommend to anyone getting confused:

  • Assume a browser
  • Disallow undefined variables
  • Disallow == and !=

External dependencies

If your code in the specific file you’re validating, it’s easy to specify those dependencies to avoid having throw an error. Just enter this code at the top of your JavaScript file (naturally, replace the names below with theobjects/methods you use):

/*global DOMAssistant, $, $$ */

JSLint web development environment integrations

Some people prefer to navigate to the JSLint page, paste in your code, and validate it, while other people feel they become faster if they can do it natively in their preferred development environment. Therefore, I’d like to offer links to tools enabling that for you:

Do you use JavaScript validation?

So, we’ve been through HTML and CSS validation, which leads us to the inevitable question:

Do you validate your JavaScript code?


  • Olly says:

    Oooh, nice tip for the external dependencies, I've been ignoring those errors πŸ˜‰

    The main reason I use JSLint is to make sure my Javascript is "valid" before pushing it through something like Packer. I had a few instances where I'd missed a semicolon or something, which wasn't a problem until the script got compressed.

  • I have actually tried but JSLint is sooooooo picky.

    I haven't been able to get it ALL right but most of it, if nothing else you get some good code convention pointers from JSLint. Like always using === and indenting with four spaces.

  • I actually hadn't heard of jslint and relied on firebug for testing javascript (that and "if it doesn't work, I should probably fix it").

    This is very helpful so I'm going to use it from now on. It gave a lot of errors on a script I'm working on now, but it didn't *really* hurt my feelings. I resolved all problems and learned some things to boot. πŸ™‚

  • I use it from within Textmate … it'll bitch at me whenever I save a file with errors or warnings πŸ™‚

  • Pelle says:

    Of course I use the online version of it for at least all of my external javascript files πŸ™‚ (sometimes I don't bother to validate the short codes I've written on pages).

    I hadn't thought about using it with Eclipse yet though πŸ™‚

  • JSLint is a good tool, but it's not perfect.

    var a = this.b = function(){}; // what's wrong? … maybe nothing?

    Anyway, applied rules are usually good practices, but we should consider how specific browser JS engine implements our code, because everyone does it in a different way.

    What I mean is how can we have a perfect "JS ruler" if every JS engine parses our code modifying them in a different way?

  • Olly says:

    @Andrea — I'm not sure I understand your point. Yes, every JS engine does things slightly differently (just like HTML, CSS and internal combustion engines), but I don't think that's really what JSLint is all about.

    It's more for syntax checking and promoting good coding practises. Think of it as an automated code review; obviously it's got it's limitations (just like any other automated validator), but it's a good starting point.

  • @Olly, what I mean, that is "only" for promoting good coding practises, because syntax checking, true syntax checking, is executed in a different way for each engine (for example, in some case a
    instead of a ; could be better to make runtime compilation faster … or not? Who knows …)

    Anyway, I agree with you about limitations, but what I meant id that if JSLint says "your code is rubbish", it doesn't mean it truly is (while W3 validator, for example, is much more accurate).

    Finally, thanks to Doug for this tool, but I could not ever integrate them in my JS development environment, for reasons I said πŸ™‚

  • Tommy Olsson says:

    Thanks for the tip about JSLint, Robert! I'd never come across it before. I tried it with a tiny JavaScript library I've made and there were few serious complaints. I did discover two minor errors and one serious issue I need to look into.

    BTW, how is browser support for the <code>===</code> and <code>!==</code> operators?

  • Andreas says:

    I JSLint most code I write but not if it's a really simple, short piece that I'm "sure" is error-free.

    My framework automagically compresses all my JS using Dean Edwards JS-packer and if it doesn't validate in JSLint it normally throws errors compressed so I guess that's a form of validation.

    Regardless, I almost always validate larger chunks of code and jQ plug-ins.

    The number of errors JSLint throws can be intimidating at first but, just like with HTML-validation, after a while you learn to avoid and understand the errors and write code that's error-free.

    BTW, I think YSlow comes with a JSLint tool. Or is it built into Firebug perhaps? There's a JSLint-option under "Tools" that validates your JS in a new window at least.

  • Robert Nyman says:

    It might be experienced as picky to begin with, but there's a reason for it: to ensure best performance and compatibility.

    And yes, integrating it into your development enviroment is a nice thing to do. πŸ™‚


    yeah, me too. I'm also using it in TextMate, but sometimes go to the site for more options.


    It is mainly about best practices, and then what's correcct code is sometimes differing between different web browsers' views. But I would say that you enctounter the sampe problems with CSS:

    You have good nice valid code, which you then need to tweak for certain web browsers (thinking hasLayout fixes of other features).


    As far as I know, the web browser support for <code>===</code> is "complete". Meaning, I haven't yet encountered a web browser which doesn't support it, and using it's a great way to avoid conversion errors.


    The number of errors JSLint throws can be intimidating at first but, just like with HTML-validation, after a while you learn to avoid and understand the errors and write code that’s error-free.

    Exactly! πŸ™‚

    And yes, YSlow offers the option of JSLint-validating the JavaScript of the web page you have navigated too (and CSS validation as well).

  • FYI: Aptana users (the standalone version or Eclipse with Aptana plugin) have JSLint installed by default. It is not activated by default though.

    It is activated by going into the preferences and via Aptana > Editors > JavaScript > Validation > JSLint JavaScript Validator.

  • Robert Nyman says:


    Great to know! I don't use Aptana myself, but it's always good to have options and know what tools are available within them.

  • […] By using three equal signs or one exclamation sign and two equal signs, it also makes sure to compare if the values are of the same type or not, i.e. both being numbers, strings etc. This is also a practice recommended when working with JSLInt. […]

  • […] fine and well, unless that if you start to validate your JavaScript with a tool such as JSLint, you’ll soon realize that using string as the first parameter in […]

  • […] fine and well, unless that if you start to validate your JavaScript with a tool such as JSLint, youÒ€ℒll soon realize that using string as the first parameter in the […]

  • Deepak says:

    Is there any validation tool that can check if a js code is compatible with various browsers.

  • Robert Nyman says:


    Interesting idea, although I'm not sure it would work. Given that there are just too many web browsers around (especially counting the mobile ones) and they might claim to support some things, but don't, or just half the way etc.

  • It just got a lot easier to utilize JsLint inside of Eclipse using RockstarApps Web Optimization Plugins. Users can simply right click inside a Eclipse Editor and Choose the menu item – "Rockstarapp -> Validate with JsLint…" and the problems will be displayed via markers in the error like Java compile errors

    Checkout the following link for more information: RockstarApps JsLint Eclipse Plugin

    Bob (Buffone)

  • Robert Nyman says:


    Great, thanks for sharing!

  • […] Do you validate your JavaScript code? […]

  • Thank you for sharing this, i am trying to write a proper JS so this might help. And just cuz is rewarding feeling when you write your code the right way πŸ™‚

  • Robert Nyman says:


    Sounds good!

  • Shogo Yahagi says:

    Everyone is validating differently based on a set of different checkmarks. What is valid for you may not be valid for me since we have different checkboxes enabled.

    In Eclipse, the rockstar plugin has some two preselected sets. “Recommended” or “Good Parts”.. otherwise you can go off on a tangent and check whatever you want.

    I would guess most people would be validating by the “Recommneded” set and others who bought Douglas’s “The Good Parts” would probably click on “Good Parts”.

    I would say we should choose one of those 2. Since Rockstar created “Recommended”.. but “Good Parts” is based off of the creator of JSLint.. I think I will choose “Good Parts” instead of “Recommended” or even going custom.

    What set of checkboxes will you choose? We need some common standard here because W3 won’t recommend one.

  • Robert Nyman says:


    I think either of those two options are good. For me it’s not about standards, but just about best practices to avoid the most common pitfalls.

  • Definitely.

    The reason we don’t validate CSS anymore is because creating valid code is extremely easy now. The only thing that the validator gets mad at is using -moz, -webkit and other “new” features.

  • Robert Nyman says:


    Well, even if it’s easy we can all still make mistakes. That’s why validation or linting tools are generally a good thing.

  • Andreas says:

    jslint doesn’t like this.

    for (var d = 0, b = c.length; d < b; ++d) {

    Problem at line 3 character 10: Stopping. (42% scanned).

    In the jslint docs it says "JSLint expects to see the comma used as a separator, but not as an operator (except in the initialization and incrementation parts of the for statement). It does not expect to see elided elements in array literals. Extra commas should not be used. A comma should not appear after the last element of an array literal or object literal because it can be misinterpreted by some browsers. "

    Is there an option to have jslint not stop on this but continue scanning ?

  • Robert Nyman says:


    Sorry, not off the top of my head.

  • John Perry says:

    I think jslint and javascriptlint are complete pants. On the one hand it’s reasonable enough to validate code for correctness, but I strongly object to their ideas of “correctness”. Why do they so abhor ‘with’? It’s in the manual, and an extremely neat way of making sure the correct elements are used. And it can be nested.
    Why do these validators check the syntax of comments?
    Why do they impose their brain-dead standards on everything? Just because it suits their own ends, why do they have to impose their arguable standards on others?
    I hate these tools, and avoid them like the plague. If my code runs like it was designed to, why should I need to revamp everything to suit their pusillanimous short-sightedness?

    So my main question is “Why is there no culture-free method of validating?”

  • Robert Nyman says:


    I believe you need to discuss that with the creator of JSLint.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.