The fight for code style or Bracket Wars
Hello habrovchanam! In this article we will try to consider such a “slippery” issue as code design and code style, and propose one of the solutions that is successful in daily practice.
For JavaScript, which for a long time remained “overboard” of a large development, the golden era of rapid development and the emergence of new and new technologies based on it has come, and applications are becoming more complex every day. Given that the adoption of annual standards, the emergence of new syntactic sugar and "buns" make it very attractive for more developers, this topic will be relevant for more than one year. Newbies in JavaScript enthusiastically take up his study, trying more and more new chips, but most of them forget about the design of the code and about such a thing as a technical duty.
What is with the stylesheet at the moment? Everything is bad: the quality of the code suffers in favor of speed of development, and this process goes back to origins by the time when JS was not considered a full-fledged programming language. However, it is worth considering the complexity of the tasks that are being solved with the help of JavaScript, and it becomes clear: this approach is fundamentally wrong and should be eradicated.
')
And this is not to mention the fact that petabytes of materials related to JavaScript are often poured into the Internet, often of very dubious quality. In some educational materials, designed for beginners, uniform hell is created. It’s not surprising that when you hire even developers with experience and programming in JavaScript, you don’t have to wait for a generated style, much less a commitment to a specific style of code design. There is no talk of understanding “best practices”.
I note that with an increase in the number of programmers, the quality of their training, knowledge, and the “lampiness” decreases with terrifying speed.
However, when you deal with commercial development in JavaScript, development of applications at different stages of readiness and numerous rotations of developers - in the end, you realize that you cannot do without a single code style within a single project.
What does he give:
What are the cons:
I knowingly put it in the name, as “Bracket Wars”. It was almost the main problem of the first stage of the implementation of a single codestyle. It was the lack of consensus on some design issues that gave rise to real holivars. I will not cover the topic of holivars, but I will try to provide a solution to this problem.
Most often, two opposite points of view can be found: “It works the same” and “In line 21 there are 7 spaces in the beginning instead of 4”. Both points of view are equally controversial. They do not have a golden mean, one will result in a terrible gossip with a huge technical debt and a bunch of angry developers who will have to deal with such an inheritance, the second can permanently stall the development and roll out of new releases. They both are not justified and lead to risks and customer dissatisfaction.
It’s just that the first one has a delayed effect - let it work now and we may have been ahead of time, but in the future, when the functionality is expanded or changed, you may encounter a lot of problems, such as debugging complexity, impossibility of expansion or such defects that cannot be eliminated without rewriting everything. written earlier.
The second one is almost instantaneous - we did not have time to implement the planned features on time, because the developer of the rules indents 70 modified files and changed 7 spaces by 2 tabs, did unplanned refactoring, did not like the rules outside of the task - he could enumerate a lot options when perfectionism calls into question the development of the project itself.
Since none of these situations is unacceptable, it is necessary to look for an alternative way and approach to the design of the code now.
Fortunately, today these problems are perfectly solved by the developer’s tools - by the IDE itself or by the plugins for them. Actually automating the process of checking and maintaining code styles and consider further the example of the three editors / IDEs that we encounter most often: Sublime Text, Atom, WebStorm.
A little bit more theory: what is covered further relates to static analysis and linting (verification) of the code, respectively, plug-ins are linters (parsers) and / or their integration into one or another editor or IDE.
Earlier, I would consider two main, in my opinion, tools - this is JSHint (static code analysis for errors) and JSCS (JavaScript CodeStyle - analysis of code design based on design agreements or individual rules), but today these 2 tools are fine replaces ESLint (almost always, but more on that below). So I will consider its integration. The main difference between ESLint and JSCS and JSHint is their modularity and great customization.
Here it is worth making a clarification on how much ESLint replaces these two tools. The JS parser, which is used in ESLint (Espree - also connected after the fact), judging by the page on npmjs , completely replaces JSHint, but more customizable than its predecessor, and slower, but for the purpose of daily support of the codestyle it has extremely low value. It should be noted that most likely, the replacement for supporting the code style rules is not yet complete, the developers of this tool themselves say that although they have joined forces with the JSCS team to implement a more versatile tool, the support is still incomplete. A list of discrepancies can be found here . Support for presets is limited. Rather, the implementation of this support has now changed its appearance, if the JSCS supported a limited set of presets out of the box, now these presets have become plug-in plug-ins, which need to be installed separately and written in the configuration file. I immediately found a preset for Yandex and presets for AirBnB and Google (the last 2 can be selected when initializing the plug-in at the time of writing this article).
It is worth expressing to the developers a special thanks for the various formats of configuration files, their automatic generation and the loading of modules with presets during the initialization of configs for EsLint.
But let's move on to the practical part, namely setting up EsLint. It is worth noting the presence of two parts of the setting: general and editor-specific. Let's start with the total.
Eslint global install:
It should be noted that when using nvm in linux, a situation may arise when eslint is not globally visible, in my case it was enough to create a symbolic link to eslint inside the / usr / local / bin / command:
where vX.XX is the version of the current Node.js that you last used in
It is needed to run at the root of your project:
This command leads to the configuration file generation dialog. Hyde is very similar to the similar package.json generation. In fact, you have 2 choices: to answer questions about the technologies used and code type or select a preset in the list, as mentioned earlier; You can choose Google, AirBnB and Standard - the recommended preset from the ESLint team. There is a third option to check the code type of your files, which essentially works the same way as polling, but also tries to determine the code style.
In fact, it’s not a very useful feature, if you have a non-ideal code style at the time of config initialization, it falls at the first grave violation. Plus you should have all the plugins globally.
Next comes the choice of the format of the configuration file - Javascript, JSON, YAML. After selecting one of the formats, the config is generated and the necessary plugins are installed. EsLint recommends using a local installation of EsLint and the necessary plugins, installs them into the working directory and writes your package.json to the devDependencies section.
At this stage, you can further customize your configuration file by following the guides on the tool site and commit the changes. For example, for the project in the reactor, I generated (answering questions about the stylestyle), and then added some rules to this config:
Let's proceed to setting up your editor.
Atom.
With the plugins for the atom, everything is clear - we put in the Install settings section the linter-eslint plugin, configure it:
We also install the linter package, if it was not installed - this is the linter-eslint dependency. It may be necessary to update the Atom, in my case, with every change in the file, a lot of errors fell out and the update of the editor solved the problem. The ease of installing plugins for Atom is one of its strengths. This plugin also fixes the codestyle when saving, if you check “Fix errors on save”.
Sublime.
Through PackageControl you need to install three plug-ins in fact. These are SublimeLinter , SublimeLinter-contrib-eslint and ESLint-formatter . The first, like linter in Atom, is the basis for the linting code in Sublime - this framework has extensive documentation , setting it up in great detail. SublimeLinter-contrib-eslint is a bridge for connecting eslint to SublimeLinter and has its own documentation and workflow in case of problems. In the settings for SublimeLinter in the linters section, you need to register the following code:
The rest is a matter of taste. Customize the look of the linter to your needs. Description of topics and settings can be found on the documentation website.
ESLint-formatter - allows you to automatically format the file according to your ESLint settings. It also needs to be configured - set the paths to Node.js and ESLint, I also recommend at least setting “format_on_save”: true. It may be worth considering project specificity and creating a .sublime-project and setting up settings for a specific project there.
WebStorm .
The setting is shown in the screenshot. It is enough to activate ESLint in Settings> Languages & Frameworks> Javascript> Code Quality Tools> ESLint , set the path to the local installation of ESLint, if it has not been determined automatically. The automatic determination of the presence of a config is recommended, but you can also specify the path to it.
The only negative thing is that I did not find automatic formatting via ESLint in WebStorm - there is an import of a stylesheet from the JSCS config and Code> Reformat Code , and there is no import from the ESLint configuration. However, the linting function works:
For WebStorm, consider this aspect and not abandon the JSCS. This is precisely the aspect that makes ESLint “almost always” replace its predecessors — its support in some IDEs still loses to JSCS and JSHint.
In conclusion, I would like to note that the rigid binding of the code style to the editor in many cases is not justified and leads to problems of setting up the environment for development. It is justified only in exceptional cases, like a uniform code style on all projects. But this is an extremely rare case. In most cases, the modularity provided by ESLint has indisputable advantages over solidity. Consider this and customize the project specifically for a particular case, and the editor is universal.
What a profit from all this:
Thanks for attention.
For JavaScript, which for a long time remained “overboard” of a large development, the golden era of rapid development and the emergence of new and new technologies based on it has come, and applications are becoming more complex every day. Given that the adoption of annual standards, the emergence of new syntactic sugar and "buns" make it very attractive for more developers, this topic will be relevant for more than one year. Newbies in JavaScript enthusiastically take up his study, trying more and more new chips, but most of them forget about the design of the code and about such a thing as a technical duty.
What is with the stylesheet at the moment? Everything is bad: the quality of the code suffers in favor of speed of development, and this process goes back to origins by the time when JS was not considered a full-fledged programming language. However, it is worth considering the complexity of the tasks that are being solved with the help of JavaScript, and it becomes clear: this approach is fundamentally wrong and should be eradicated.
')
And this is not to mention the fact that petabytes of materials related to JavaScript are often poured into the Internet, often of very dubious quality. In some educational materials, designed for beginners, uniform hell is created. It’s not surprising that when you hire even developers with experience and programming in JavaScript, you don’t have to wait for a generated style, much less a commitment to a specific style of code design. There is no talk of understanding “best practices”.
I note that with an increase in the number of programmers, the quality of their training, knowledge, and the “lampiness” decreases with terrifying speed.
However, when you deal with commercial development in JavaScript, development of applications at different stages of readiness and numerous rotations of developers - in the end, you realize that you cannot do without a single code style within a single project.
What does he give:
- Readability. Structured code is always more readable than unstructured, otherwise we would immediately write code that is close to minified, and weren't steamy.
- Uniformity. An important aspect, which many for some reason do not think about. The human brain is a lazy thing, it forms a kind of inline cache to read the source code, and as a result, switching between different style pieces or files takes time to form new reading patterns. How do you think it would be great if the developer, while moving from file to file, “hangs” to form a new reading model? Hardly.
- A single code design style makes it possible to free developer resources that he spends reading and redefining the design style for their more productive use. For example, besides the unconditional acceleration of development, he can see “narrow” areas in the code, potential performance losses, defects and other garbage, and accordingly see opportunities for improvements.
- Quick entry of a new developer. This clause, like clause 3, is rather a consequence of uniformity and readability. The new developer will still have to build an inline cache for reading, but due to uniformity this cache will be built once for one project. And ideally - if all projects follow the same style - then once.
What are the cons:
- Every developer should know code style
- It takes a lot of time to support code styles.
- It takes time to resolve conflicts about which quotes are more correct or on which line to put brackets.
I knowingly put it in the name, as “Bracket Wars”. It was almost the main problem of the first stage of the implementation of a single codestyle. It was the lack of consensus on some design issues that gave rise to real holivars. I will not cover the topic of holivars, but I will try to provide a solution to this problem.
Most often, two opposite points of view can be found: “It works the same” and “In line 21 there are 7 spaces in the beginning instead of 4”. Both points of view are equally controversial. They do not have a golden mean, one will result in a terrible gossip with a huge technical debt and a bunch of angry developers who will have to deal with such an inheritance, the second can permanently stall the development and roll out of new releases. They both are not justified and lead to risks and customer dissatisfaction.
It’s just that the first one has a delayed effect - let it work now and we may have been ahead of time, but in the future, when the functionality is expanded or changed, you may encounter a lot of problems, such as debugging complexity, impossibility of expansion or such defects that cannot be eliminated without rewriting everything. written earlier.
The second one is almost instantaneous - we did not have time to implement the planned features on time, because the developer of the rules indents 70 modified files and changed 7 spaces by 2 tabs, did unplanned refactoring, did not like the rules outside of the task - he could enumerate a lot options when perfectionism calls into question the development of the project itself.
Since none of these situations is unacceptable, it is necessary to look for an alternative way and approach to the design of the code now.
Fortunately, today these problems are perfectly solved by the developer’s tools - by the IDE itself or by the plugins for them. Actually automating the process of checking and maintaining code styles and consider further the example of the three editors / IDEs that we encounter most often: Sublime Text, Atom, WebStorm.
A little bit more theory: what is covered further relates to static analysis and linting (verification) of the code, respectively, plug-ins are linters (parsers) and / or their integration into one or another editor or IDE.
Earlier, I would consider two main, in my opinion, tools - this is JSHint (static code analysis for errors) and JSCS (JavaScript CodeStyle - analysis of code design based on design agreements or individual rules), but today these 2 tools are fine replaces ESLint (almost always, but more on that below). So I will consider its integration. The main difference between ESLint and JSCS and JSHint is their modularity and great customization.
Here it is worth making a clarification on how much ESLint replaces these two tools. The JS parser, which is used in ESLint (Espree - also connected after the fact), judging by the page on npmjs , completely replaces JSHint, but more customizable than its predecessor, and slower, but for the purpose of daily support of the codestyle it has extremely low value. It should be noted that most likely, the replacement for supporting the code style rules is not yet complete, the developers of this tool themselves say that although they have joined forces with the JSCS team to implement a more versatile tool, the support is still incomplete. A list of discrepancies can be found here . Support for presets is limited. Rather, the implementation of this support has now changed its appearance, if the JSCS supported a limited set of presets out of the box, now these presets have become plug-in plug-ins, which need to be installed separately and written in the configuration file. I immediately found a preset for Yandex and presets for AirBnB and Google (the last 2 can be selected when initializing the plug-in at the time of writing this article).
It is worth expressing to the developers a special thanks for the various formats of configuration files, their automatic generation and the loading of modules with presets during the initialization of configs for EsLint.
But let's move on to the practical part, namely setting up EsLint. It is worth noting the presence of two parts of the setting: general and editor-specific. Let's start with the total.
Eslint global install:
npm i -g eslint It should be noted that when using nvm in linux, a situation may arise when eslint is not globally visible, in my case it was enough to create a symbolic link to eslint inside the / usr / local / bin / command:
ln -s /usr/local/nvm/vX.XX/bin/eslint /usr/local/bin/eslint where vX.XX is the version of the current Node.js that you last used in
nvm use XXX It is needed to run at the root of your project:
eslint --init This command leads to the configuration file generation dialog. Hyde is very similar to the similar package.json generation. In fact, you have 2 choices: to answer questions about the technologies used and code type or select a preset in the list, as mentioned earlier; You can choose Google, AirBnB and Standard - the recommended preset from the ESLint team. There is a third option to check the code type of your files, which essentially works the same way as polling, but also tries to determine the code style.
In fact, it’s not a very useful feature, if you have a non-ideal code style at the time of config initialization, it falls at the first grave violation. Plus you should have all the plugins globally.
Next comes the choice of the format of the configuration file - Javascript, JSON, YAML. After selecting one of the formats, the config is generated and the necessary plugins are installed. EsLint recommends using a local installation of EsLint and the necessary plugins, installs them into the working directory and writes your package.json to the devDependencies section.
At this stage, you can further customize your configuration file by following the guides on the tool site and commit the changes. For example, for the project in the reactor, I generated (answering questions about the stylestyle), and then added some rules to this config:
{ "env": { "browser": true, "es6": true, "commonjs": true }, "extends": [ "eslint:recommended", "plugin:react/recommended" ], "installedESLint": true, "parserOptions": { "ecmaFeatures": { "experimentalObjectRestSpread": true, "jsx": true }, "sourceType": "module" }, "plugins": [ "react" ], "rules": { "indent": [ "warn", "tab" ], "linebreak-style": [ "warn", "unix" ], "quotes": [ "warn", "double" ], "semi": [ "warn", "always" ], "react/prop-types": "off", "no-console": "off", "no-unused-vars": "off" } } Let's proceed to setting up your editor.
Atom.
With the plugins for the atom, everything is clear - we put in the Install settings section the linter-eslint plugin, configure it:
We also install the linter package, if it was not installed - this is the linter-eslint dependency. It may be necessary to update the Atom, in my case, with every change in the file, a lot of errors fell out and the update of the editor solved the problem. The ease of installing plugins for Atom is one of its strengths. This plugin also fixes the codestyle when saving, if you check “Fix errors on save”.
Sublime.
Through PackageControl you need to install three plug-ins in fact. These are SublimeLinter , SublimeLinter-contrib-eslint and ESLint-formatter . The first, like linter in Atom, is the basis for the linting code in Sublime - this framework has extensive documentation , setting it up in great detail. SublimeLinter-contrib-eslint is a bridge for connecting eslint to SublimeLinter and has its own documentation and workflow in case of problems. In the settings for SublimeLinter in the linters section, you need to register the following code:
"linters": { "eslint": { "@disable": false, "args": [], "excludes": [] } } The rest is a matter of taste. Customize the look of the linter to your needs. Description of topics and settings can be found on the documentation website.
ESLint-formatter - allows you to automatically format the file according to your ESLint settings. It also needs to be configured - set the paths to Node.js and ESLint, I also recommend at least setting “format_on_save”: true. It may be worth considering project specificity and creating a .sublime-project and setting up settings for a specific project there.
WebStorm .
The setting is shown in the screenshot. It is enough to activate ESLint in Settings> Languages & Frameworks> Javascript> Code Quality Tools> ESLint , set the path to the local installation of ESLint, if it has not been determined automatically. The automatic determination of the presence of a config is recommended, but you can also specify the path to it.
The only negative thing is that I did not find automatic formatting via ESLint in WebStorm - there is an import of a stylesheet from the JSCS config and Code> Reformat Code , and there is no import from the ESLint configuration. However, the linting function works:
For WebStorm, consider this aspect and not abandon the JSCS. This is precisely the aspect that makes ESLint “almost always” replace its predecessors — its support in some IDEs still loses to JSCS and JSHint.
In conclusion, I would like to note that the rigid binding of the code style to the editor in many cases is not justified and leads to problems of setting up the environment for development. It is justified only in exceptional cases, like a uniform code style on all projects. But this is an extremely rare case. In most cases, the modularity provided by ESLint has indisputable advantages over solidity. Consider this and customize the project specifically for a particular case, and the editor is universal.
What a profit from all this:
- No “Bracket Wars”. The toolkit cares about code styles, not you. This gives space for kostruktiva instead holivary;
- You do not need to know code style anymore - in any case, force its study and implant. Over time, the developer will remember the specific rules, and if he misses something, “fix on save” will save everyone;
- Code Style support is automatic, it does not require developer time;
- The project is homogeneous in style, and this gives all the buns that were described at the beginning of the article in the “pluses”.
Thanks for attention.
Source: https://habr.com/ru/post/304304/
All Articles