Words by Vernacchia

Yes, you should lint your code*.

Showing my age again, I remember when there were so many linters for JS. There was JSLint, JSHint, ESLint, and likely many more.

Finally, ESLint emerged as the default linter, with almost all companies adopting it.

I was on Twitter (yes, it’s “Twitter”) and saw this tweet from Michael Jackson:

After I got over my initial rage of someone suggesting that linting was not important, I realised it is all situational.

Before we get too far, let’s talk about Prettier. Prettier is an opinonated code formatter, not a linter, with the main goal of enforcing consistent code style.

This is super different from a linter, which is more about finding and fixing problems in your code.

Now that we got that cleared up, we’ll be focusing fully on linters!

Should you lint your code?

This is a great question. I usually ask myself a few questions before deciding when to lint my code.

1. How big is the project?
2. How many people are working on the project?
3. Is the project a personal, work, or OSS project?
4. Is the project a PoC or a production-ready project?
5. Do I care about errors??? (a bit of a joke, but also serious)

Yes, I should lint my code!

I’d lint my code if:

• It’s a big project is and a lot of people working on it
• A lot of people contribute to the project
• The project will be used in production
• I do care about catching errors before they happen
• It’s a work project

Nah, I can get away without…

• I know it’s a work PoC, and it will be thrown away after (is this really ever the case though?)
• It’s a personal project, and I’m the only one working on it
• I’m only working on it, and I want to move fast (I’ll still use a formatter)

Yeah, but has it really saved you??

Yes… There’s been so many things that linters have caught at my places of work.

One that helps all the time is import/resolver. This is less helpful now that we have amazing IDEs that do a lot of these things automatically, but it still catches things!

Essentially, this catches incorrect imports. If you try to import something from a file that doesn’t exist, BOOM, error.

Does it always save you??

And no, it doesn’t always save you. We recently had a problem where the linter didn’t throw an error when an undefined function was called.

The function was supposed to be imported into the file, but, unfortunately it wasn’t. This caused a runtime error.

After some investigation, it turns out ESLint’s no-undef rule would’ve saved us. We thought it was enabled, but unfortunately, it wasn’t. This was because:

… plugin:@typescript-eslint/recommended turns off no-undef because it’s covered by TS, so double reporting is somewhat useless.

The reasoning makes sense, as TS should catch these errors (and the files in the offending PR were TS). But, it didn’t. Why?

TL;DR - we’d disabled type checking because we were incrementally adopting TS across our codebase.

You can bet that we’ve enabled that rule now!

Long story short

You should lint your code if you work in a professional setting where many people contribute to a long-lived codebase (where you care about consistency and standards as time goes on).

Until next time...