"Standard" JS style

"Standard" JS style

2016-10-31 10:09 by Nievidong, 2099 Read, comments, collection , Edit

First of all, this JS style guide has been in our front-end team for more than half a year;
Second, in the programmer's world, from the entry to the senior have to face several world-class problems, such as:

1. What is the best editor in the world?
2. Do you use a space or a TAB? With the space also special to derive 2 space VS 4 space.
3. JS do you want to write a semicolon?
4. ...

Finally, PHP is the best language in the world.

I. Norms VS FREEDOM

For every programmer, code specification is not necessarily a good thing, because it will definitely affect the freedom of writing code.
For example, a programmer used to tab, the team introduced a specification to be replaced by Spaces, which is not "bad news" for the TAB party.

Especially for older programmers, if the code style that has been used for years needs to be changed (first and good or bad), it's really a very screwed-up thing.

But for the entire team, having code specifications is definitely a big thing. And because there are too many advantages, such as convenient management, good maintenance, easy to read and so on, so I do not have to list, we all understand:

If, a set of code specifications and even the code flow, can make the team members are relatively satisfied, but also can effectively execute ... I want to say: Please cherish this good time.

At present, the various manufacturers, various open source projects have a variety of JS specifications. Today this article introduced the JS specification is called "Standard Style", is definitely the most widely used one of the wording (star 7800+), but also provides the supporting tools, plug-ins can be easily used.

Ii. introduction of "JS Standard Style"

Standardjs is the name of this project.
By the way, its author, Feross, advises programmers to get a sense of how vicious the "big man" in the world of programmers can be.

Please take a closer look at this JS specification point, the rules:

• 2 spaces –for indentation
• single quotes for strings–except to avoid ESCAP ing
• No unused variables–this One catches tons of bugs!
• No semicolons – it ' s fine. really!
• never start a line with (, [, or '
• This is the only gotcha with omitting semicolons–automatically checked For you!
• Space after keywords if (condition) {...}
• Space after function name Function name (ARG) {...}
• always use = = = instead of ==–but obj = = null is allowed to check null | | undefined.
• always handle the node. js Err function parameter
• always prefix browser globals with window–except document and navigator is okay
• prevents accidental use of the Poorly-named browser globals like open, length, event, and name.
• and more goodness–give standard a try today!

Yes, first of all, regardless of the benefits and advantages of this specification, but the two conditions I marked are really a bit of a killer: no semicolon; 2 spaces .

The discussion about whether there is a semicolon can write many papers;
As for the tab or the space ... Can trigger a programmer's jihad.

So here is a good look, want to know more students, it is strongly recommended that you secretly search for more information. PS: For Mao to search privately? Please refer to, I actually just want to consider for your safety:)

Three, the first simple use up!

The official demo is presented using NPM script.
One sentence: The global installation of standard this package, and then use the CLI is to achieve the subsequent operation and display.

$ NPM Install standard--global

This approach is well suited for use as a validation audit for JS code. Such as:

However, if you want to cooperate with the daily development, to achieve automatic reminders, or even automatic formatting, I highly recommend with the corresponding editor plug-in to use.

Iv. Cooperate with editor plugin

The main reason I like and recommend this specification is--no configuration!
PS: If you have known ESLint, in the face of all kinds of configuring and Rules, special how many people can insist to read, anyway, I gave up.

But using Standardjs, it has already set the rules, so if you accept its rules, then you can just use it without a brain. Such as:

There are many editors that support the Standardjs plugin, and almost all of the editors used in the front end are covered by:
Sublime Text, Atom, Vim, Emacs, Brackets, Visual Studio Code, Webstorm/phpstorm.

Space is limited, just introduce the use and effect under the Atom editor. Atom needs to install the corresponding two plugins:

• Linter-js-standard-linter plugin for JavaScript standard Style
• Standard-formatter-format file contents using JavaScript standard Style

Effects such as:

Ah ~ It's a beautiful time.

V: How to implement a unified code style in your project

Not every programmer has code cleanliness, and not every programmer is paranoid to write good code, more ordinary people actually just want to less toss the work to complete the good.
So for the implementation of code norms within the team, let it be natural.

However, the use of the following scheme can make this set of norms more smooth implementation.

The first step: using ESLint in the project, install the corresponding package:

• Eslint
• Eslint-config-standard
• Eslint-plugin-promise
• Eslint-plugin-standard

The second step: the editor installs the corresponding plugin to atom example:

• Linter-js-standard
• Linter
• Linter-eslint
• Standard-formatter

Last step: Add. eslintrc in the project, just one line

Extends:standard

The development of the automatic format is so realized, think is not a little excited about it.
PS: I hope you have an inclusive heart, because in the past six months, we have indeed encountered a number of small problems, the use of StackOverflow and open source projects corresponding to the Issue, all kinds of problems you can find the answer.

Vi. Summary: Talk about the advantages and disadvantages

To this set of JS specification itself, has been in the generalities, advantages and shortcomings of the exposition scattered everywhere, I am in this simple comb under my personal understanding it.

The advantages:

• reading the code will be a good mood -the longer the working life, the more you can understand the meaning of this sentence, which is also my most concern, who will have a good mood to read the first bad code, and no one would like to read a hundreds of line, but there are several sets of code style code.
• No need to learn the ESLint of trouble, no configuration.
• There is a "no unused variables" in the specification, but it is really useful. Unused variables will prompt you to optimize, reduce code, and even locate problems.
• Think about it, if the team has new entrants, don't worry too much about his code style, regardless of his working life.
• Have a routine, good maintenance.

About the disadvantages:

• If the "JS standard Style" of a specification has objection, can I change it? Answer: No.
• Will affect the freedom of the few. Unilaterally offend other programmers, such as the Tab party, the 4-space party.
• Our entire team uses Atom, with the corresponding plug-ins, occasionally a little bit of a problem. The almighty StackOverflow and issue will help us.
• Right, do not be the name of this set of norms to cheat, this is not really the JS standard, the real JS Standard is still in the discussion of the no play it.

That's how I feel about using this set of specs.

Finally, thanks to the outstanding Desen classmate (Ali nickname "Full stack", I asked you not afraid). He was forced to add this set of stuff to our Nodejs Docker project, so we had to use it, haha haha haha.

"Standard" JS style