Despite many years of experience, people still type variable names incorrectly, make syntax errors and forget to handle errors properly and forget about the best practices in hurry. But its important to write the quality code. A good linting tool, or a linter, will help to check the code errors and the standard style before someone waste their time—or worse, client’s time.
First of all, I will be describing some standard javascript rules and then the lint tools available to check for javascript standard and how the tools can be integrated with IntelliJ IDEA.
Some Standard JavaScript rules.
-
Use 2 spaces for indentation
-
Use single quotes for strings except to avoid escaping.
-
No unused variables
-
Add a space after keywords.
-
Add a space before a function declaration’s parentheses.
-
Always use=== instead of ==.
-
Infix operators must be spaced
-
Commas should have a space after them
-
Always handle the err function parameter
Lint Tools
Despite many years of experience, one can still type variable names incorrectly, make syntax errors and forget to handle errors properly. A good linting tool, or a linter, will tell about this before wastage of time—or worse, client’s time. A good linting tool can also help make sure a project adheres to a coding standard. A linting tool helps to avoid silly mistakes when writing JavaScript.
Different Lint Tools
Different tools available are:
-
JSLint
-
JSHint
-
JSCS
-
ESLint
JSLint
Pros
-
Comes configured and ready to go (if you agree with the rules it enforces)
Cons
-
JSLint doesn’t have a configuration file, which can be problematic if you need to change the settings
-
Limited number of configuration options, many rules cannot be disabled
-
You can’t add custom rules
-
Undocumented features
-
Difficult to know which rule is causing which error
JSHint
JSHint was created as a more configurable version of JSLint (of which it is a fork). You can configure every rule, and put them into a configuration file, which makes JSHint easy to use in bigger projects.
Pros
-
Most settings can be configured
-
Supports a configuration file, making it easier to use in larger projects
-
Has support for many libraries out of the box, like jQuery, QUnit, NodeJS, Mocha, etc.
Cons
-
Difficult to know which rule is causing an error.
-
Has two types of option: enforcing and relaxing (which can be used to make JSHint stricter, or to suppress its warnings). This can make configuration slightly confusing.
-
No custom rule support
JSCS
JSCS is different from the others in that it doesn’t do anything unless you give it a configuration file or tell it to use a preset
Pros
-
Ready-made configuration files can make it easy to set up if you follow one of the available coding styles
-
Has a flag to include rule names in reports, so it’s easy to figure out which rule is causing which error
-
Can be extended with custom plugins
Cons
-
Only detects coding style violations. JSCS doesn’t detect potential bugs such as unused variables, or accidental globals, etc.
-
Slowest of the four, but this is not a problem in typical use
ESLint
Pros
-
Flexible: any rule can be toggled, and many rules have extra settings that can be tweaked
-
Very extensible and has many plugins available
-
Easy to understand output
-
Includes many rules not available in other linters, making ESLint more useful for detecting problem
Cons
-
Some configuration required.
-
Slow, but not a hindrance.
After considering the pros and cons, I would suggest to use ESLint. Even the JSCS and ESLint teams have agreed upon making ESLint together instead of competing with each other.
How to use?
Three requirements :
1) It requires Node.js
2) To include ESLint as part of your project’s build system. (I.e having esLint installed)
3) You should then setup a configuration file (having .eslintrc.json file).
To run ESLint using intellij:
- File | Settings | Languages and Frameworks | JavaScript | Code Quality Tools | ESLint
-
Support displaying eslint warnings as intellij inspections
Configuring Rules:
(Rules can be added in .eslintrc.json):
{
“rules”: {
“semi”: [“error”, “always”],
“quotes”: [“error”, “double”]
}
}
The names “semi” and “quotes” are the names of rules in ESLint. The first value is the error level of the rule and can be one of these values:
-
“off” or 0 turn the rule off
-
“warn” or 1 – turn the rule on as a warning (doesn’t affect exit code)
-
“error” or 2 – turn the rule on as an error (exit code will be 1)
Sample .eslintrc.json file :
References:
1) https://github.com/eslint/eslint
2) https://www.sitepoint.com/comparison-javascript-linting-tools/
Reblogged this on pranjut.
Thank you! Very helpful for newbies trying to form good habits.