How to keep a consistent coding style and avoid bugs before production.
Posted
Updated
Europe’s developer-focused job platform
Let companies apply to you
Developer-focused, salary and tech stack upfront.
Just one profile, no job applications!
In an ideal world there would be no errors, because errors are bad, especially when writing code. Some errors cause glitches that frustrate users or compromise security. The best thing is to avoid them, as good as you can. As a developer you have the benefit of modifying your workflow, hence you can easily add a linter.
Linting can help us to reduce errors and improve code quality. The definition of a linter, according to wikipedia is: "lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs." wikipedia
💰 The Pragmatic Programmer: journey to mastery. 💰 One of the best books in software development, sold over 200,000 times.
So basically a linter is a basic static code analyzer, it checks your source code for programmatic and stylistic errors (wrong indentation, variable naming, ...).
For example:s
const msg = 'This is my first message!'
console.log(msg)
const msg = 'This is my second message!'
If you are using a linter you'll get an error:
error: Identifier 'msg' has already been declared
In the javascript world there are several linters available. The most used ones are: ESLint, JSLint, JSHint and TSLint (TypeScript).
Stats: 7.381M Downloads - VS Code 15.8k Github ⭐
In the javascript world ESLint would be the most seen one. If you work with Typescript you can also use ESLint (yes, there will be a post about this. 😇). ESLint has 15.7k Stars on Github and the repository is quite active, so it's worth checking it out.
ESLint is similar to JSLint or JSHint, but there are exceptions:
Espree is basically a JavaScript parser with a modular architecture based on Acorn, which is also a JS parser.
AST (Abstract Syntax Tree) is used for describing a particular syntax pattern in your code, see the example AST below.
Explore the Abstract Syntax tree for your javascript code yourself, on astexplorer.net.
To get started with ESLint, install it globally or as a development dependency:
npm install eslint --save-dev
# or
npm install eslint --global
Important: If you install ESLint globally, the configuration will apply to all projects you run it against. If you want a different configuration for each project, you have to install it as a dev dependency with the flag --save-dev
.
To start the configuration of ESLint, run the command.
eslint --init
You will be guided through a setup wizard. You always have to start with the initialization of ESLint to create the configuration file. The questions in setup wizard are quite self-explanatory:
If some dependencies, like eslint-plugin-react
is missing, it will prompt to install it.
After the installation, you should have a configuration file in the root folder of your project. Below you can see the basic eslint config file for a react project.
{
"env": {
"browser": true,
"es6": true,
"node": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended"
],
"globals": {
"Atomics": "readonly",
"SharedArrayBuffer": "readonly"
},
"parserOptions": {
"ecmaFeatures": {
"jsx": true
},
"ecmaVersion": 2018,
"sourceType": "module"
},
"plugins": [
"react"
],
"rules": {
}
}
What configuration should you use? If you are starting from scratch with ESLint, you can base your configuration on a popular style guide. If it this sound too intimidating for you, you can also use it completely and modify your config file over time. One of the most popular style guides for Javascript is the Airbnb Javascript Style Guide.
Stats: 101k Downloads - VS Code 3.3k Github ⭐
JSLint was created in 2002 by Douglas Crockford. Maybe you know this $book from him? Andrew Hyndman made a VS Code extension, which is used by ~101k developers. The online version of JSLINT features a text field, where you can check your code direct on the website. It supports ES6, at least the good parts of it.
JSLint is opinionated, which can be a blessing or a curse. If you have to use a style guide in your project, JSLint may not be the ideal tool for you. In my opinion, it's great for smaller projects, I've used it in the past with good old vanilla javascript.
Stats: 1.165M Downloads - VS Code 8.3k Github ⭐
JSHint started as a fork of JSLint with the goal to make a more configurable Linter. JSHint is not opinionated like JSLint and can be customized. It also has a website with a text field to paste code and lint on the website directly, you even get some metrics about your code like how many functions your code contains and of course linting errors.
If you don't like this copy/paste method, JSHint can be installed using npm:
npm install jshint --global
# or
npm install jshint --save-dev
Once installed, you’ll use the command line interface (CLI) to lint your code, like so:
# check one file
jshint index.js
# check directory
jshint src
JSHint can be customized using a file named .jshintrc
, see below:
{
"esversion": 5,
"eqeqeq": true,
"strict": true
}
This customization sets the ECMAScript to version 5, uses ===
instead of ==
and enforces strict mode.
The config file can be created in the root folder in the project and then added to the JSHint config, with this command:
jshint --config './.jshintrc'
Or you add the config to the package.json
like so:
{
"jshintConfig": {
"esversion": 5,
"eqeqeq": true,
"strict": true
}
}
There are more configuration options and you can fully customize JSHint. The official DOCS contain all the config options and more information about the JSHint API.
Stats: 1.647M Downloads - VS Code 5.6k Github ⭐
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. So basically, JavaScript that scales.Typescript was developed by Microsoft and it's open source. More information in the github repo.
TSLint is de facto the standard linter for TypeScript repositories and for the TypeScript implementation itself. TSLint is maintained by Palantir and they want to deprecate TSLint and focus on making ESLint support TypeScript. 😀
In a recent blog post the Palantir Group posted:
[...] In order to avoid bifurcating the linting tool space for TypeScript, we therefore plan to deprecate TSLint and focus our efforts instead on improving ESLint’s TypeScript support.
So if you are using TypeScript instead of JavaScript, because of the many benefits in debugging and writing clean code, you probably already have TSLint installed.
If you are just starting out with TypeScript or want to add the TSLint to your project, you have to install it:
# local
npm install tslint typescript --save-dev
yarn add tslint typescript --dev
# global
npm install tslint typescript -g
yarn global add tslint typescript
The typescript package is a peer dependency of TSLint. This allows you to update the compiler independently from the linter. This also means that tslint will have to use the same version of tsc which is used to actually compile your sources.
Keep in mind that an update to the newest version of typescript with typescript@next
can eventually cause the linter to malfunction.
Please ensure that the TypeScript source files compile correctly before running the linter.
Quick Start in CLI after installing TSLint:
# Navigate to your sources folder
cd path/to/project
# Generate a basic configuration file
tslint --init
# Lint TypeScript source globs
tslint -c tslint.json 'src/**/*.ts'
The basic syntax of tslint is tslint [options] [file ...]
.
Available parameters for [options]
:
-v, --version output the version number
-c, --config [config] configuration file
-e, --exclude <exclude> exclude globs from path expansion
--fix fixes linting errors for select rules (this may overwrite linted files)
--force return status code 0 even if there are lint errors
-i, --init generate a tslint.json config file in the current working directory
-o, --out [out] output file
--outputAbsolutePaths whether or not outputted file paths are absolute
--print-config print resolved configuration for a file
-r, --rules-dir [rules-dir] rules directory
-s, --formatters-dir [formatters-dir] formatters directory
-t, --format [format] output format (prose, json, stylish, verbose, pmd, msbuild, checkstyle, vso, fileslist, codeFrame)
-q, --quiet hide non "error" severity linting errors from output
--test test that tslint produces the correct output for the specified directory
-p, --project [project] tsconfig.json file
--type-check (deprecated) check for type errors before linting the project
-h, --help output usage information
By default, TSLint looks for a configuration file named tslint.json in the directory of the file being linted and, if not found, searches ancestor directories.
To generate a tslint config file:
# Generate a basic configuration file
tslint --init
There are plenty of different rules for the config file, which are categorized in:
All the TSLint rules can be found in the DOCS.
After starting tslint in the command line the CLI process may end with one of these codes:
If you use TypeScript instead of JavaScript in your project, you have to use ESLint or TSLint for type checking. Personally, I like to use TypeScript very much, it helps prevent bugs and gives a cleaner structure to the code. The downside when using TypeScript is more code, but this can be neglected with all the benefits gained.
My recommendation is to use TypeScript and hence TSLint or ESLint with TypeScript support. If you want to use a linter in a JavaScript project, I'd recommend using ESLint.
Thanks for reading and if you have any questions, use the comment function or send me a message on twitter @mariokandut.
References: Farley Reynolds, Colby, Google ESLint Config, AirBnB ESLint Config, Robin, Palantir and many more.
Never miss an article.