从谷歌的JavaScript编写风格中，13 点值得我们注意的！

2023-02-26

let good bad

 对于那些还不熟悉JavaScript的编写风格的人，谷歌提供了编写JavaScript的编写风格指南，谷歌风格指南其中列出了编写干净、可理解代码的***风格实践。对于编写有效的JavaScript来说，这些并不是硬性的、快速的规则，而只是在源文件中维护一致的、吸引人的样式选择的规则。这对

对于那些还不熟悉JavaScript的编写风格的人，谷歌提供了编写JavaScript的编写风格指南，谷歌风格指南其中列出了编写干净、可理解代码的***风格实践。

对于编写有效的JavaScript来说，这些并不是硬性的、快速的规则，而只是在源文件中维护一致的、吸引人的样式选择的规则。这对于JavaScript来说尤其有趣，它是一种灵活且多变的语言，允许多种风格的选择。

谷歌和Airbnb有两个***的编写风格指南。如果我的工作是花费大量时间编写JS，那么可以先学习这两种方法。

以下是谷歌JS风格指南中我认为最有趣和相关的13条规则：

谷歌JS风格指南处理各种各样的问题，从激烈争论的问题(制表符与空格的比较，以及分号应该如何使用这个有争议的问题)，到一些更模糊的规范，这些规范令我吃惊，它们肯定会改变我以后写JS的方式。

对于每个规则，我将对规范进行总结，然后引用样式指南中的支持部分，详细描述该规则。在适用的情况下，我还将提供实践中的样式示例，并将其与不遵循规则的代码进行对比。

使用空格，而不是制表符

除了行结束符序列之外，ASCII水平空格字符(0x20)是源文件中出现在任何位置的惟一空格字符。这意味着…制表符不用于缩进

使用两个空格(而不是四个)进行缩进

// bad  
function foo() {  
∙∙∙∙let name;  
}  
// bad  
function bar() {  
∙let name;  
}  
// good  
function baz() {  
∙∙let name;  
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.

分号是必需的

每个语句必须以分号结束，禁止依靠自动分号插入。

虽然无法想象为什么会有人反对这个想法，但JS中分号的一致使用正在成为新的“空格对制表符”的争论。谷歌一惯建议结束需要使用分号。

// bad  
let luke = {}  
let leia = {}  
[luke, leia].forEach(jedi => jedi.father = 'vader')  
// good  
let luke = {};  
let leia = {};  
[luke, leia].forEach((jedi) => {  
  jedi.father = 'vader';  
}); 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

不要使用ES6模块

不要使用ES6模块(即导出和导入关键字)，因为它们的语义还没有最终确定。注意，一旦语义完全标准，将重新定义使用的方式。

// 先别做这种事  
//------ 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'; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

不鼓励(但不禁止)水平对齐

这种做法是允许的，但谷歌编写风格通常不鼓励这样做，甚至不需要在已经使用它的地方保持水平对齐。

水平对齐是在代码中添加可变数量的额外空格，以使某行变量的值与前面变量值对齐。

// bad  
{  
  tiny:   42,    
  longer: 435,   
};  
// good  
{  
  tiny: 42,   
  longer: 435,  
}; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

不要再使用var了

使用const或let声明所有本地变量来代替 var。默认情况下使用 const，除非需要重新分配变量在使用 let 声明。

// bad  
var example = 42;  
// good  
let example = 42; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

箭头函数是***

箭头函数提供了简洁的语法，并解决了this 在函数中不确定性的一些问题，与function关键字相比，更喜欢箭头函数，特别是对于嵌套函数。

老实说，我只是觉得箭头函数很棒因为它们更简洁，更美观。事实证明，它们还有一个非常重要的用途。

// 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;  
}); 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

使用模板字符串而不是拼接客串

在复杂的字符串连接上使用模板字符串(用`分隔)，特别是在涉及多个字符串文本时，模板字符串可以跨越多行。

// 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}?`;  
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.

不要对长字符串使用 \ 来表示连续

不要在普通或模板字符串文字中使用连续行(也就是说，在字符串文字中以反斜杠结束一行)。尽管ES5允许这样做，但是如果斜杠后面有任何尾随空格，那么可能会导致一些棘手的错误，而且对读者来说不太明显。

有趣的是，谷歌和Airbnb不同意这个规则(这是Airbnb的规范)。

虽然谷歌建议连接更长的字符串(如下所示)，Airbnb的风格指南基本上建议什么也不做，并允许长字符串继续，只要他们需要。

// bad (sorry, this doesn't show up well on mobile)  
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.'; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.

for…of是for循环的***类型

使用ES6，该语言现在有三种不同的for循环。所有的循环都可以使用，但是如果可能的话，for-of循环应该是***的。

如果您问我，这是一个奇怪的问题，但是我认为我应该包含它，因为谷歌声明了一种***的for循环类型，这非常有趣。

我总觉得 for...in 循环对于对象更好，而对于for...of 的更适合数组，不同场景可以使用不同方式。

虽然这里的Google规范不一定与这个想法相矛盾，但是了解他们特别喜欢这个循环还是很有趣的。

不要使用eval()

不要使用eval或function(…string)构造函数(代码加载器除外)。这些特性具有潜在的危险，而且在CSP环境中根本不起作用

MDN 页面的eval()中，甚至有一个名为“不要使用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 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

常量应该用全大写字母命名，用下划线分隔

常量名称使用CONSTANT_CASE的格式:所有大写字母，单词由下划线分隔。

如果您绝对确信某个变量不应该更改，那么可以通过将该常量的名称大写来表示。这使得在整个代码中使用该常量时，它的不变性非常明显。

一个值得注意的例外是，如果常量是函数作用域的。在这种情况下，应该用camelCase来写。

// bad  
const number = 5;  
// good  
const NUMBER = 5; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

每次声明一个变量

每个局部变量声明只声明一个变量:声明如令a = 1, b = 2，不推荐。

// bad  
let a = 1, b = 2, c = 3;  
// good  
let a = 1;  
let b = 2;  
let c = 3; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

使用单引号，而不是双引号

普通的字符串用单引号(')分隔，而不是双引号(")。

提示:如果字符串包含单引号字符，可以考虑使用模板字符串来避免转义引号。

// 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`; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.