Javascript Style Checker

Table of contents
Reading Time: 5 minutes

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



  • Comes configured and ready to go (if you agree with the rules it enforces)


  1. JSLint doesn’t have a configuration file, which can be problematic if you need to change the settings

  2. Limited number of configuration options, many rules cannot be disabled

  3. You can’t add custom rules

  4. Undocumented features

  5. Difficult to know which rule is causing which error


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.


  1. Most settings can be configured

  2. Supports a configuration file, making it easier to use in larger projects

  3. Has support for many libraries out of the box, like jQuery, QUnit, NodeJS, Mocha, etc.


  1. Difficult to know which rule is causing an error.

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

  3. No custom rule support


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


  1. Ready-made configuration files can make it easy to set up if you follow one of the available coding styles

  2. Has a flag to include rule names in reports, so it’s easy to figure out which rule is causing which error

  3. Can be extended with custom plugins


  1. Only detects coding style violations. JSCS doesn’t detect potential bugs such as unused variables, or accidental globals, etc.

  2. Slowest of the four, but this is not a problem in typical use



  1. Flexible: any rule can be toggled, and many rules have extra settings that can be tweaked

  2. Very extensible and has many plugins available

  3. Easy to understand output

  4. Includes many rules not available in other linters, making ESLint more useful for detecting problem


  1. Some configuration required.

  2. 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 :





Written by 

Sangeeta is a Software Consultant and has experience of more than 2 years. She was successful in winning the inter-college competition: Venture Exposition (Project Presentation) in Innotech-Technical Event, at LBSIM. She is familiar with different technologies which include Scala, Java, Play Framework, Hadoop, Spark, HTML, CSS, Javascript. Her Hobbies include dancing, painting and practicing yoga.

4 thoughts on “Javascript Style Checker8 min read

Comments are closed.