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:
- JavaScript Tools TextMate bundle
- Verifying Javascript files with JSLint from Eclipse IDE
- JSLint.VS – JavaScript Verifier for Visual Studio
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?
23 Comments/Reactions
April 17th, 2008 at 10:35
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.
April 17th, 2008 at 10:51
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.
April 17th, 2008 at 11:05
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.
April 17th, 2008 at 11:11
I use it from within Textmate … it’ll bitch at me whenever I save a file with errors or warnings
April 17th, 2008 at 11:48
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
April 17th, 2008 at 12:18
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?
April 17th, 2008 at 12:52
@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.
April 17th, 2008 at 18:01
@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 \n 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
April 18th, 2008 at 6:54
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
===and!==operators?April 18th, 2008 at 7:48
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.
April 18th, 2008 at 9:33
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.
Morgan,
yeah, me too. I’m also using it in TextMate, but sometimes go to the site for more options.
Andrea,
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).
Tommy,
As far as I know, the web browser support for
===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.Andreas,
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).
April 24th, 2008 at 7:52
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.
April 24th, 2008 at 9:29
Anders,
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.
May 16th, 2008 at 8:02
[...] 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. [...]
December 16th, 2008 at 13:05
[...] 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 [...]
December 27th, 2008 at 21:44
[...] 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 [...]
January 15th, 2009 at 18:25
Is there any validation tool that can check if a js code is compatible with various browsers.
January 16th, 2009 at 11:23
Deepak,
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.
January 26th, 2009 at 5:39
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)
January 26th, 2009 at 7:29
Bob,
Great, thanks for sharing!
November 25th, 2009 at 4:38
[...] Do you validate your JavaScript code? [...]
March 24th, 2010 at 23:35
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
March 25th, 2010 at 11:00
Izdelava,
Sounds good!
Write a comment
Twitter reactions