What you need to know about the JavaScript code specifications released by Google

Code specification is not a rule for writing correct JavaScript code, but a choice to keep the source code writing pattern consistent. This article introduces to you what you need to know about the JavaScript code specifications released by Google. Friends who are interested should take a look.

Google has released a JS code specification for those who are not familiar with the code specifications. It lists best practices for writing concise and understandable code.

Code specification is not a rule for writing correct JavaScript code, but a choice to keep the source code writing pattern consistent. This is especially true for the JavaScript language, as it is flexible and less restrictive, allowing developers to use many different coding styles.

Google and Airbnb each occupy half of the most popular coding standards. If you will invest a long time in writing JS code, I strongly recommend that you read through the coding standards of these two companies.

What I want to write next are the thirteen rules that I personally think are closely related to daily development in Google's code specifications.

The issues they deal with are very controversial, including tabs and spaces, whether to force the use of semicolons, etc. There are also some rules that surprise me and often end up changing my habits of writing JS code.

For each rule, I will first give a summary of the specification and then quote the detailed description from the specification. I will also give some appropriate counterexamples to demonstrate the importance of following these rules.

Use spaces instead of tabs

In addition to the terminator sequence of each line, the ASCII horizontal space character (0x20) is the only one that can appear in the source A space character anywhere in the file. This also means that the tab character should not be used and used to control indentation.

The specification later states that indentation should be achieved using 2 spaces instead of 4.

// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}

The semicolon cannot be omitted

Each statement must end with a semicolon. Relying on JS's ability to automatically add semicolons is not allowed.

Although I don't understand why anyone would object to this rule, the use of semicolons has apparently become as controversial as the "spaces vs tabs" issue. Google said that the semicolon is necessary and cannot be omitted.

// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
 jedi.father = 'vader';
});

Don’t use ES6 module yet

Because the semantics of ES6 modules are not yet complete OK, so don't use keywords such as export and import for now. Once their specifications are finalized, please ignore this rule.

// 暂时不要编写下面的代码：
//------ lib.js ------
export function square(x) {
  return x * x;
}
export function diag(x, y) {
  return sqrt(square(x) + square(y));
}
//------ main.js ------
import { square, diag } from 'lib';

Translator's Note: I feel that it is unrealistic to follow this rule. After all, babel already exists. And when using React, the best practice is to use ES6 modules.

Horizontal alignment of code is not recommended

Google's code specifications allow but do not recommend horizontal alignment of code. Even if horizontal alignment was done in the previous code, this behavior should be avoided in the future.

Aligning the code horizontally will add some extra spaces in the code, which makes the characters on two adjacent lines appear to be on a vertical line.

// bad
{
 tiny:  42, 
 longer: 435, 
};
// good
{
 tiny: 42, 
 longer: 435,
};

Avoid var

Use const or let to declare all local variables. If the variable does not need to be reassigned, const should be used by default. Use of the keyword var should be rejected.

I don’t know if it’s because no one can convince them, or if it’s because old habits die hard. Currently I still see many people using var to declare variables on StackOverFlow or elsewhere.

// bad
var example = 42;
// good
const example = 42;

Prefer arrow functions

Arrow functions provide a concise syntax , and avoid some problems about this pointing. Compared with the function keyword, developers should give priority to using arrow functions to declare functions, especially to declare nested functions.

To be honest, I once thought that the role of arrow functions was only to be simple and beautiful. But now I find that they have a more important role.

// bad
[1, 2, 3].map(function (x) {
 const y = x + 1;
 return x * y;
});
// good
[1, 2, 3].map((x) => {
 const y = x + 1;
 return x * y;
});

Use template string instead of connection string

When dealing with multi-line characters Template strings perform better than complex concatenated strings.

// bad
function sayHi(name) {
 return 'How are you, ' + name + '?';
}
// bad
function sayHi(name) {
 return ['How are you, ', name, '?'].join();
}
// bad
function sayHi(name) {
 return `How are you, ${ name }?`;
}
// good
function sayHi(name) {
 return `How are you, ${name}?`;
}

Don’t use line continuation characters to split long strings

In JS, \ also represents the line continuation character. Google's coding standards do not allow the use of line continuation characters in either template strings or ordinary strings. Although this is allowed in ES5, if \ is followed by some terminating whitespace, this behavior can lead to errors that are difficult to notice when reviewing the code.

This rule is very interesting, because there is a different rule in Airbnb's specifications

Google recommends the following writing method, while Airbnb believes that it should be allowed to take its course and not do anything special. Process it as long as it needs to be.

// bad (建议在PC端阅读)
const longString = 'This is a very long string that \
  far exceeds the 80 column limit. It unfortunately \
  contains long stretches of spaces due to how the \
  continued lines are indented.';
// good
const longString = 'This is a very long string that ' + 
  'far exceeds the 80 column limit. It does not contain ' + 
  'long stretches of spaces since the concatenated ' +
  'strings are cleaner.';

优先使用for...of

在ES6中，有3种不同的for循环。尽管每一种有它的应用场景，但Google仍推荐使用for...of。

真有趣，Google居然会特别指定一种for循环。虽然这很奇怪，但不影响我接受这一观点。

以前我认为for...in适合遍历Object，而for...of适合遍历数组。因为我喜欢这种各司其职的使用方式。

尽管Google的规范与这种使用方式相冲突，但Google对for...of的偏爱依然让我觉得十分有趣。

不要使用eval语句

除非是在code loader中，否则不用使用eval或是Function(...string)结构。这个功能具有潜在的危险性，并且在CSP环境中无法起作用。

MDN中有一节专门提到不要使用eval语句。

// bad
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
eval( 'var result = obj.' + propName );
// good
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

常量的命名规范

常量命名应该使用全大写格式，并用下划线分割

如果你确定一定以及肯定一个变量值以后不会被修改，你可以将它的名称使用全大写模式改写，暗示这是一个常量，请不要修改它的值。

遵守这条规则时需要注意的一点是，如果这个常量是一个函数，那么应该使用驼峰式命名法。

// bad
const number = 5;
// good
const NUMBER = 5;

每次只声明一个变量

每一个变量声明都应该只对应着一个变量。不应该出现像let a = 1,b = 2;这样的语句。

// bad
let a = 1, b = 2, c = 3;
// good
let a = 1;
let b = 2;
let c = 3;

使用单引号

只允许使用单引号包裹普通字符串，禁止使用双引号。如果字符串中包含单引号字符，应该使用模板字符串。

// bad
let directive = "No identification of self or mission."
// bad
let saying = 'Say it ain\u0027t so.';
// good
let directive = 'No identification of self or mission.';
// good
let saying = `Say it ain't so`;

总结

就像我在开头所说那样，规范中没有需要强制执行的命令。尽管Google是科技巨头之一，但这份代码规范也仅仅是用来当作参考罢了。

Google是一家人才汇聚的科技公司，雇佣着出色的程序员来编写优秀的代码。能够看到这样的公司发布的代码规范是一件很有趣的事情。

如果你想要实现一种Google式的代码，那么你可以在项目中制定这些规范。但你可能并不赞成这份代码规范，这时也没有人会阻拦你舍弃其中某些规则。

我个人认为在某些场景下，Airbnb的代码规范比Google的代码规范要出色。但不管你支持哪一种，也不管你编写的是什么类型的代码，最重要的是在脑海中时刻遵守着同一份代码规范。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

Ajax发送和接收请求

ajax异步加载图片实例分析

浅析json与jsonp区别及通过ajax获得json数据后格式的转换

The above is the detailed content of What you need to know about the JavaScript code specifications released by Google. For more information, please follow other related articles on the PHP Chinese website!