JSCS: JavaScript Code Style
When I wrote a small console utility for myself nine months ago, I didn’t suspect that it would soon become a serious and unique tool that even well-known commands like jQuery , Bootstrap , Angular will use . Now, when I am writing this article, my project on a githab is 1010 stars, and I am very happy to think that so many people could make their work more convenient with the help of my notion.
The story of this project began with my personal pain.
Shortly before this point, I transferred from one Yandex.Maps team to another and gradually poured into the development of a new product for me. Everything was good, I liked the new project, but the code style in which the guys from my new team wrote was very much different from the coding style in which I wrote and the guys from my previous team. Once, I was even visited by the ridiculous idea that the code style in this group was written as opposed to the code style in the previous group specifically to confuse me.
')
For example…
One day I finished developing a new visual block and sent it to the creatreview, so that the guys would look at it for defects in logic. That's how he looked then.
It was in this review that disappointment awaited me.
Imagine, I spent a whole week doing a new form of feedback, debugging, putting the code in order. But the very first comment I received in the review was: “There is no space after the function”. And exactly the same in 5 places of the code ?!
Do not misunderstand me. I developed the product, tried. He came up with a non-trivial logic, in which there were no errors at all. But I could not go through the review just because I forgot to put a space after the word “function” ?! I did not like it. I wanted the reviewers to pay attention to my code, to its architecture, to defects in logic, and not to violations of the command style.
I felt sad. Then there was a second review like this, and the same situation with the space after the “function” repeated. This gap was given to them! And at that moment I clearly understood that I could not go on like this. I'm pissed off.
This is how the JavaScript Code Style was born, JSCS for short, is a tool that informs me about all style code violations before I send the code to the review. For a long time in this utility there was only one rule that checked if there was a space after the “function”. And that was enough for me to feel happy. If I happened to forget to insert this unfortunate space again, the JSCS informed me about this before each commit:
For a while I used this utility alone, I did not share it with anyone. What for? I solved my problems and calmed down. But it soon became clear that many of my colleagues had the same problems with the stylestyle. Only they did not leave a space after the “function” forgot to put, but, for example, add a line break at the end of the file. I shared with them.
JSCS began to spread inside Yandex. He began to rapidly acquire new rules. Different commands, different code styles - new interesting rules began to appear, for example, a ban on implicit type conversion (
If you ask me what caused such an explosive growth in the popularity of this project, I will answer.
In the first place, such a valuable tool did not exist at that moment, and I am not sure what it is now. The second reason is that the tool is designed to solve one small, understandable to all, relevant to many, task. And the third, in my opinion, very important reason - I was able to make a tool with a simple and obvious software architecture. That is, the tool does not try to solve a bunch of diverse tasks, it does one thing, but it does it very well.
Why did you not begin to expand jshint, because before jshint had a number of rules for checking the style of the code?
These rules were incomplete, chaotic, and the jshint developers themselves wanted to get rid of them. That is why Ticket No.102 appeared in the repository of JSCS, where Mike (Mike Sherov) began to transfer the style check rules from jshint to jscs. Now in the new version of jshint, there is not a single rule for checking stylistics, and JSCS has become the only comprehensive tool that solves this problem.
And the project has two more permanent maintainers. They turned out to be guys who are engaged in the development of the jQuery core - Mike Sherov ( mikesherov ) and Oleg Gaidarenko ( markelog ), they rake a huge number of tickets that come from users. And those stars, which earned the project on the githaba, their great merit. Thank you guys so much!
Project page on githaba: https://github.com/mdevils/node-jscs . This page describes more than 60 rules with which you can set up a valid code type in a project.
Come, use, suddenly and you will also like it.
The story of this project began with my personal pain.
Shortly before this point, I transferred from one Yandex.Maps team to another and gradually poured into the development of a new product for me. Everything was good, I liked the new project, but the code style in which the guys from my new team wrote was very much different from the coding style in which I wrote and the guys from my previous team. Once, I was even visited by the ridiculous idea that the code style in this group was written as opposed to the code style in the previous group specifically to confuse me.
')
For example…
One day I finished developing a new visual block and sent it to the creatreview, so that the guys would look at it for defects in logic. That's how he looked then.
It was in this review that disappointment awaited me.
Imagine, I spent a whole week doing a new form of feedback, debugging, putting the code in order. But the very first comment I received in the review was: “There is no space after the function”. And exactly the same in 5 places of the code ?!
Do not misunderstand me. I developed the product, tried. He came up with a non-trivial logic, in which there were no errors at all. But I could not go through the review just because I forgot to put a space after the word “function” ?! I did not like it. I wanted the reviewers to pay attention to my code, to its architecture, to defects in logic, and not to violations of the command style.
I felt sad. Then there was a second review like this, and the same situation with the space after the “function” repeated. This gap was given to them! And at that moment I clearly understood that I could not go on like this. I'm pissed off.
This is how the JavaScript Code Style was born, JSCS for short, is a tool that informs me about all style code violations before I send the code to the review. For a long time in this utility there was only one rule that checked if there was a space after the “function”. And that was enough for me to feel happy. If I happened to forget to insert this unfortunate space again, the JSCS informed me about this before each commit:
For a while I used this utility alone, I did not share it with anyone. What for? I solved my problems and calmed down. But it soon became clear that many of my colleagues had the same problems with the stylestyle. Only they did not leave a space after the “function” forgot to put, but, for example, add a line break at the end of the file. I shared with them.
JSCS began to spread inside Yandex. He began to rapidly acquire new rules. Different commands, different code styles - new interesting rules began to appear, for example, a ban on implicit type conversion (
!!x - bad, Boolean(x) - good). A little later, I laid the JSCS on the githab. And then the rules began to be added by external (relatively to Yandex) people. And suddenly the stars fell down.If you ask me what caused such an explosive growth in the popularity of this project, I will answer.
In the first place, such a valuable tool did not exist at that moment, and I am not sure what it is now. The second reason is that the tool is designed to solve one small, understandable to all, relevant to many, task. And the third, in my opinion, very important reason - I was able to make a tool with a simple and obvious software architecture. That is, the tool does not try to solve a bunch of diverse tasks, it does one thing, but it does it very well.
Why did you not begin to expand jshint, because before jshint had a number of rules for checking the style of the code?
These rules were incomplete, chaotic, and the jshint developers themselves wanted to get rid of them. That is why Ticket No.102 appeared in the repository of JSCS, where Mike (Mike Sherov) began to transfer the style check rules from jshint to jscs. Now in the new version of jshint, there is not a single rule for checking stylistics, and JSCS has become the only comprehensive tool that solves this problem.
And the project has two more permanent maintainers. They turned out to be guys who are engaged in the development of the jQuery core - Mike Sherov ( mikesherov ) and Oleg Gaidarenko ( markelog ), they rake a huge number of tickets that come from users. And those stars, which earned the project on the githaba, their great merit. Thank you guys so much!
Project page on githaba: https://github.com/mdevils/node-jscs . This page describes more than 60 rules with which you can set up a valid code type in a project.
Come, use, suddenly and you will also like it.
Source: https://habr.com/ru/post/220229/
All Articles