How ESLint analyzes code and fights Legacy

We tell how front-end developer Dmitry Balaev @manmo and I remove Legacy, what Open Source configurations we use for ESLint, and how the static code analyzer influenced the development of our company’s developers.

What is Legacy and where does it come from

Legacy code is heavily maintained, low-quality or outdated code that is impossible to understand (or possible, but for a very long time). Often, Legacy means the code that the team receives as a “legacy” from previous developers. But not everything is so simple: the code that [хорошие] development teams are handed over to the customer, Legacy cannot be named, because such code can be quickly and easily figured out.

The main reasons for Legacy:

In the life of any developer, there comes a moment of collision with the “mammoth”. We were working on a project where the code was written back in 2000. Then about any ES6 it was impossible even to dream. For 20 years, hundreds of developers have changed to support that project. Each of them wrote in a way that was convenient for him, using his own methodology and convenient technologies. Due to such situations, a unified style of writing code is not obtained, but crutches in the JS code, incorrectly used variables in CSS, and much more are obtained.

This reason follows from the previous one. On finished projects, Legacy is almost inevitable, but it can also occur when creating completely new products – more on that in the next paragraph.

To work on a new project, as a rule, a team is assembled from free resources. These can be developers of different grades – from Junior to Senior, who have previously worked with other stacks and other requirements. If a good team leader didn’t take on a new project from the very beginning and didn’t build suitable requirements, the code will again turn out without a single style with all the ensuing consequences.

Clear instructions do not negate the human factor, so even very strong teams need a Code review. There is no Code review – there is Legacy and constant picking in Pull Requests. You need to remember the style of each project, and for developers it’s hard. Code review should solve this problem.

Ideally, you need to get rid of Legacy, do refactoring, bring the code to a uniform readable form. For an old 20-year-old project, this is very labor intensive, since changing a small piece of code can lead to the collapse of the entire project, and sometimes it is easier and more expedient to rewrite it from scratch. But for a new project, in which signs of Legacy have just begun to appear, the situation can be corrected – to build work under the guidance of an experienced team leader and write clear requirements for developers.

How to remove Legacy

There are a number of tools that will help you refactor and “fit” the code to the same standards. In this article, we will look at a few static code analyzers (hereinafter referred to as SCA) – they analyze the program code without actually executing it.

JSLint is a web-based SCA for JavaScript programs that verifies that they conform to coding standards. It was developed by American programmer and entrepreneur Douglas Crockford (Douglas Crockford) in 2002. Douglas is developing the JavaScript language. He popularized the JSON data format and developed various JavaScript related tools such as JSLint and JSMin. Once installed, the analyzer is immediately ready for use. The downside is that JSLint is not customizable or extensible. The official documentation is very weak.

JSHint used in software development to verify that JavaScript source code conforms to coding rules. JSHint was created in 2011 by Anton Kovalev as a fork of the JSLint project. Anton is currently working security engineer at Medium. JSHint has good documentation and easy integration into editors. Of the minuses – it is difficult to determine which rules cause errors.

ESLint is a tool for identifying problematic patterns found in JavaScript code. It was created by Nicholas Zakas (Nikolas, Zakas) in 2013. Nicholas contributed to the development Yahoo! User Interface (YUI) librarycreated Cookie Utility, profiler, YUI Testhis three books on JavaScript translated into Russian. With the help of the ESLint analyzer, you can set rules for finding errors and find them easily. Many plugins are available for it, any rule can be switched, many of them have additional settings. The result is predictable, plus ESLint has convenient support for ES6 and reactive frameworks.

We use ESLint on all our projects, as it is an evolution of previous linters. I’ll tell you how we set it up and share the results of implementation.

How to set up ESLint

When creating projects on modern frameworks, the analyzer can already be built in with the initial settings. For example, when initializing a new project on Nuxt, the system suggests installing ESLint:

To install ESLint into an existing project, add it via npm “npm install eslint –save-dev” and create a configuration file “.eslintrc”. For instant highlighting of errors, you can configure the code editor. Additional plugins are also installed via npm.

On the network you can find many Open Source configurations for ESLint. These are regular node.js packages with the “eslint-config-” prefix, which contain only the ESLint configuration from a specific company/team/developer. For example, you can easily use ready-made configurations from Google or Airbnb.

Sometimes you may want to disable rules in a specific location or file. This can be done in several ways:

/* eslint-disable */
/* eslint-enable */


console.log(‘test’); // eslint-disable-line

You can also disable specific rules:

/* eslint-disable no-console */
/* eslint-enable no-console */


console.log(‘test’); // eslint-disable-line no-console
// eslint-disable-next-line no-console

Not all developers agree with the implementation of ESLint, as they are used to writing code in their own way and do not want to rebuild. There were times when some developers simply ignored the rules, made a pull with errors. In this case, the library can help pre-commit, which does not allow you to commit if there are errors. But this can lead to someone turning off certain settings or ESLint itself. In this case, only proper control and Code review on the project will help.

When maintaining a project with ESLint already configured, these rules must be followed. You don’t need to disable or change anything. As they say, “they don’t climb into someone else’s garden with their shovel,” even if someone else’s config is not familiar to us.

What is the result

To completely get rid of Legacy, you need to spend a lot of time on painstaking manual work. ESLint itself will not be able to do this, but it’s quite possible to help in this and facilitate hard work.

Here is how our company was affected by the implementation of ESLint:

  • We save time on project support by about 30%.

  • Faster and easier training of new employees/trainees/juniors. They immediately see how to write cleaner code.

  • We are improving the code: it becomes cleaner in terms of the number of libraries, because it’s not too lazy to write your own custom code and transfer developments from past projects.

  • We eliminate obvious, banal errors, which sometimes take time to find, for example, writing to a previously created variable or a missing character.

  • We free up time to check our code. Now the developers devote their freed hours to better layout layout, creative animation, and so on. This allows you to get more cool projects.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *