10 ESLint Rules You Should Use

There are many helpful tools in the programming world that can simplify, speed up, and make your work more comfortable. One of these instruments is ESLint. ESLint is a static code analyzer for your JavaScript code, which helps to create and support the project's code style, prevents some code issues, and also enforces the best practices for code writing. ESLint is easily and highly configurable, so you can build up your own project-specific rules.

In this article, I will tell about 10 base rules that I personally use in my projects and why they matter.

camelCase

This rule enforces to use camelCase for your names which is the common practice for JavaScript.

quotes

Double (““) and single (‘‘) quotes in JavaScript are the same from the functional and performance perspective, so you need to choose between them based on your project rules and personal preferences. But you must choose something, do not mix them in your code base. I prefer single quotes

no-multiple-empty-lines

You can easily restrict the count of empty lines between code lines. Yes, it is very convenient to divide the code into logical areas, but you should not get too carried away with it - one empty line is enough. It ensures code consistency and reduces vertical scrolling a little

@angular-eslint/component-selector/@angular-eslint/directive-selector

These two rules are from Angular world and quite similar so I combined them into one. They suggest writing selectors for your components and directives with a project prefix and in one style. For example, the directives should be written in a camelCase, meanwhile the components in kebab-case. The prefix is helpful to distinguish your components/directives from the third-party or native ones.

no-plusplus

There are several reasons to enable this rule and perhaps the most valuable is the Automatic Semicolon Insertion (although can easily be leveraged by semi rule). It is not technically necessary to put the semicolon at the end of each line - just start writing your code from the new line and the interpreter will manage it by itself (usually, it will put the semicolon at the end of the line). And this can be a spot of issues. For example:

let i = 1;
let j = 2;

i
++
j

// will be i = 1; j = 3

let i = 1;
let j = 2;

i++
j

// will be i = 2; j = 2

Also, this rule enforces using the same style of increment/decrement for the whole project, which keeps your code in one style. You can add

{ "allowForLoopAfterthoughts": true }

for this rule if you want to use unary increment/decrement for the for loops.

ban/ban

This rule is quite useful for scenarios when you need to restrict the usage of deprecated functions or some others. One more case - fit and fdescribe in unit tests. All tests, except tests with this function, will be skipped from the run. It is useful when you need to run several tests in one big (or not so much) suite for debugging purposes, but it's not a good idea to push them into a remote repository.

no-console

The simple is that - we forbid the usage of the console.log to eliminate the chances of pushing it into a remote repository. All of the debugging tools should be kept on the local machine

no-unused-vars

The rule is self-describing - forbidding the usage of unused variables. Sometimes, while developing a new functionality or refactoring an existing one, we leave some unused code that should be cleaned up. If you are in for a long time in this context it is quite difficult to notice such details. This rule will hint you such places that you can remove

unused-imports/no-unused-imports

In addition to the above rule - restrict the usage of unused imports. Yes, we can easily notice it locally (since it will be with a gray color in most IDEs), but in code review, it is challenging to do it

no-duplicate-imports

The most of time we need to import something from the same place. It can be done in two ways:

1. One line import:

   import { a, b, c } from 'module';
   

2. In several lines:

   import { a } from 'module';
   import { b } from 'module';
   import { c } from 'module';
   

This rule enforces importing in one line which improves readability because you can find all your imported staff in one place

Conclusion

ESLint helps you to make your development process a little bit faster, and simpler and supports your code in one code style that you can create by yourself. It allows aiming at the important things - the application business logic and not paying attention to a code style (respect your code reviewers). The described rules definitely help you in this journey and remember, that you have almost unlimited rules, configs, and settings variations. You should use the rules that are perfectly suitable for your team and project requirements.