JS Standard

Use spaces , Instead of using tab

• Except for the line terminator , In the system file , Spaces are the only characters that represent white space , It means tab Cannot be used as an indent . Regulations with 2 A space （ instead of 4 individual ） To indicate indentation .

An indispensable semicolon

• Every statement must end with a semicolon , Don't rely on the compiler to automatically insert semicolons .

Don't use var

• Declare local variables with const perhaps let, By default const, Unless the variable needs to be reassigned .

The arrow function perfectly replaces function

• Arrow functions are not only syntactically simple and easy to read , And fixed this The problem of , Especially in nested functions .

Replace string splicing with template string

• Use template string （ use ` Division ） Handle complex strings , Especially when dealing with multi line strings .

Don't wrap long strings with backslashes

• although ES5 That's allowed , But it will lead to strange mistakes , And it will mislead people who read the code

for Cycle preference “for… of”

• stay ES6 in , Support for multiple for Cyclic writing , Maybe you've used it all , But try to choose for… of Well .

Do not use eval()

• Do not use eval() （ Except code loaders ）, It will bring about potential uncertainty , Because in CSP Does not work in the environment .

Constants are underlined with capital letters

• Constants are represented by uppercase letters and underscores , All words are capitalized , Underline split .

Declare one variable at a time

• Declare one variable at a time , Don't write as let a = 1, b = 2;

single quote , Don't use double quotes

• Ordinary strings are separated by single quotation marks （’）, If the string contains single quotes , Then consider using the template string .

name

• css Class name , Use lowercase English + -;
• function , Name the hump ;

notes

• Legal information （ For example, copyright and copyright notices ）
• Provide notes for information （ For example, explain the return value of an abstract method , Of course, it is better to reflect in the method name , Thus omitting the notes ）
• The interpretation of intention （ Explain your intentions to some code that doesn't seem to conform to common sense , Such as sleep function ）
• Caution （ Warn code that will have some consequences after execution ）
• TODO notes （ Tell the others that there is still work to be done , And what it should be like when it is finished in the future ）
• avoid
  • Redundant comments log comments （ Record each modification log , At present, the source code management is very perfect today , Logging comments should be discarded ）
  • Annotated code （ Don't comment out the code directly ！ Delete if useless , Comments rather than deletions can lead others to think that this code is still useful ）
  • Ownership and signature （ Through source code management , Signatures can also be discarded ）
  • Comments after parentheses （ Do not write comments after parentheses ）
  • Too much information （ Don't add irrelevant information to your comments ）

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your teamhttps://serious-lose.notion.site/JS-Standard-7b2e7b72e0da4678a9fd19cd74b6cd1a