Thoughts on Web Development

After working as a developer for quite some time (over a decade), I’ve recently started to train other developers and teams in ways to improve their front-end development skillsets and processes.

Javascript 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 javascript?” I say, “Lint your javascript.”

Sometimes I instead say, “Yo. You need to lint your Javascript.”

Or, “Seriously, lint your Javascript. For realz, brah.”

WTF is Javascript linting?

“Linting” means running a very basic code quality tool which will look at your Javascript, 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.)

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 production

Most 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 Conflicts

Ever 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.

Javascript Linting Tools

Today’s linting tools are JSHint (new, fairly common, and the one I recommend), ESLint (newer, sounds 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 browser

Paste 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 editor

Sublime 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 line

If 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 process

This 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.

The Bottom Line

Start linting your Javascript by some means immediately, if you’re not already. It’ll make you a better developer with less stress and more time (presumably for chasing after QA girls or guys).

Great points, Eric. This article was more of an intro to linting as a concept than a review of tools – for people who don’t lint at all, they just need to do it by any means for starters. But those are compelling reasons to try ESLint.

I haven’t worked with JS Standard yet, but it looks like a good potential option for minimal setup and taking the thinking out of code style. Some, especially junior-ish devs could probably benefit a lot from the guard rails approach.