Javascript Linting: What Developers Need to Know
MC
Developer TrainingFreelance ProgrammingWeb Development
After working as a developer for quite some time (decades), I’ve recently started to train other developers and teams in ways to improve their front-end development skillsets and processes.
Linting
is one of the least talked about, but most essential tools in a front-end developer’s toolbox. So when people ask “What’s the easiest thing we can do to improve our code?” I say, “Lint your stinkin’ JavaScript.”Sometimes I instead say, “Yo. You need to lint yourJavaScript.”
Or, “Seriously, lint yourJavaScript. For realz, brah.”
WTF is Javascript linting?
“Linting” means running a very basic code quality tool which will look at yourJavaScript, and tell you where and how to clean it up.
In other words, it’s something that can AUTOMATICALLY find the dumb mistakes we all make, so you can fix them without thinking. It’ll make your code break less and prevent some very confusing problems.
Why linting is important
Top 5 reasons you should be linting your JavaScript:
- It prevents certain types of bugs, including a few catastrophic ones.
- It saves you time.
- It makes your code better.
- It’s easy.
- It’ll get you laid more.
(Ok it won’t really get you laid, but then again neither will web development – usually. So I’ll assume you’re in this for business reasons. Moving on.)
It definitely will improve your skills, by guiding you toward better coding habits while you work and practice (this is vital: see Keep Your Swords Sharp).
Oh and it can make your code cleaner, which will make you look cooler to other developers. So if you’ve got your sights set on that QA engineer with the thick glasses, this may mean there’s hope for you yet.
Problems linting can prevent
Linting tools issue warnings about certain types of code smells that can lead to common problems. Some are quite major.
Problem #1: Works in development, breaks in productionMost modern web stacks support minification, but the minifiers won’t tell you when you’re missing semicolons, and neither will your browser. But a missing semicolon can break minified javascript.
Why this sucks: your code will work nice and happy in development. Then you’ll deploy to production – shit breaks, and you don’t know why. Customers complain. Your boss yells at you. You swear the code works! Chaos ensues.
Problem #2: Scope ConflictsEver create a variable called “id” or “name” or “value?” Yeah, so has every other developer in history, including people that will work on the same codebase as you. And if someone forgets to declare all their variables with var, they can overwrite each other unexpectedly.
If you have variables with the same name in multiple places, and someone forgets to use var even once, you bet your sweet ass your variable can get overwritten with a value you didn’t expect.
And it will happen. They will forget. You will forget. Chaos ensues…you get the picture.
Problem #3..N: Many More.Linting your JS can prevent potential XSS security holes, readability problems, etc.
JavaScript Linting Tools
Today’s linting tools are JSHint (new, fairly common, and the one I recommend), ESLint (newer, powerful) and JSLint (the original JS linting tool).
I recommend JSHint because:
- It’s more user-friendly and configurable than JSLint.
- It’s pretty common and has a good amount of community support.
- I haven’t used ESLint enough to recommend it yet.
But use whichever as long as you get’er done.
How to use JavaScript linting tools
There are different means by which to use linting tools to improve your code quality. Let’s start out with the training wheels.
Linting manually, in the browserPaste some code you’re really proud of into www.jshint.com with a big, cheery smile on your face. Then wipe that silly smile off your face as jshint tells you how much your code sucks. Brutal.
This is the quickest way to get started with linting, but there are more ideal means.
Linting from your code editorSublime text has plugins for all of the linters above, and I’d imagine most IDEs today do as well. Grab one and have it check your code automatically, or with a keystroke.
This is particularly great since it’s unobtrusive; you’re already in your editor, might as well clean your code up while you write it.
Linting from the command lineIf you’re using a command line tool like Grunt or Gulp, you’re ahead of the curve. You may have a linter installed already, and if not there is a JSHint plugin for each of those.
If you’re even slicker, you can install something like grunt-contrib-watch to run the linter every time you change your JS, and lint as you code.
Linting as part of a build processThis is the best way to ensure that these types of problems never see the light of day. When you or another developer leaves some lint in your code and goes to deploy, everything grinds to a halt until you fix it.
What else you need to know
The linting tools can be sensitive, to the point of being anal – like your third grade english teacher who shamed you every time you wrote “its” instead of “it’s.”
JSHint is better than JSLint in this regard, which is why I prefer it. But it can also give you a lot to read when you first use it. Luckily, it’s also very configurable.
I recommend turning off most of your linter’s settings when you first start using it, so that you have a minimal set of errors to start with. Take the ones it spits out, learn what they mean, then fix them. Then re-enable another setting and repeat. This way your code gets better gradually, without you getting overwhelmed.