原文地址：13 Noteworthy Points from Google’s JavaScript Style Guide
原文作者：Daniel Simmons
译者：命名最头疼
对编码风格不熟悉的人而言，Google 推出一套用于编写 JavaScript 代码的样式指南， 并指出（谷歌认为）编写清晰易懂的代码最佳风格。
首先声明一点，以下规则并不是编写 Javascript 代码的硬性要求，仅是为了维持项目代码的一致性，Javascript 是一种灵活而宽松的语言，它允许各种风格。
Google 和 Airbnb 都推出了各自的编码风格指南，且是比较受欢迎的，如果你的项目中需要编写大量的JS代码，我绝对建议你阅读。
以下列出了在 Google JS 风格指南中我认为比较有趣且实用的 13 条规则
Google对编码中的每个细节点都进行了争议(标签, 空格,以及分号的使用)还有一些模糊的规范, 无疑, 这套风格肯定会改变我写JS的方式。
对每一条规则，我都会列出规范的摘要部分，然后是样式指南中的支持引用和详细描述规则，在恰当的情况下，我将举例说明，并与之和不遵循规则的代码进行对比。
推荐使用空格, 而不是tab键
除了行终止符以外，ASCII 中的水平空格字符 (0x20) 是唯一一个表示空格的空白字符，这意味着 Tab 键并不适用于缩进。
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
推荐使用分号, 而不是将其省略
每条语句结束后必须带有分号，严禁依赖编译器自动插入分号。 虽然我无法想象为什么有人会反对这个想法，但是 JS 中一贯使用分号将成为新 "spaces versus tabs" 争论，Google 表示坚持分号的使用。
// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
jedi.father = 'vader';
});
不要使用 ES6 模块
不要使用 ES6 模块（即 export 和 import 关键词），因为它们的语义尚未最终确定，注意，一旦语义完全标准化，将重新审视这条规则。
// 现在先不要这样用:
//------ 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';
不推荐水平对齐（但不禁止）
首先水平对齐这种做法是允许的，但是在 Google 风格中并不推荐这种用法。甚至不需要在已使用过的地方保持水平对齐。 水平对齐即在代码中添加空格，使每一列对齐。
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
不要再使用var
使用 const 或 let 声明所有局部变量，除非需要重新分配变量，否则默认使用 const，不推荐使用 var 关键词。 我仍然看见人们在 StackOverflow 和其他地方使用 var 代码示例。可能有人会为此反对，或者说这是一种旧习惯，要改变，比较困难。
// bad
var example = 42;
// good
let example = 42;
首选箭头函数 箭头函数提供一个简洁的句法，并解决了许多困难，首选箭头函数而不是函数关键词，尤其是嵌套函数 说句真心话，我认为箭头函数非常棒，因为他们更加简洁，更好看，事实证明，他们也有很重要的作用。
// 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;
});
使用模板字符串代替连接符
在复杂字符串上使用模板字符串 （``） 而是不是连接符 （+） ，特别是涉及多个字符串文字的情况下，模板字符串可以跨行
// 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}?`;
}
对长字符串不要使用行连续符
不要在普通字符串或模板字符串中使用行连续（即, 通过反斜杠结束字符串文字内的一行）尽管 ES5 允许这样做，如果有空格尾随在后面，它将会导致棘手的错误，并且对读者来说不那么明显。
有趣的是，Google 和 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.';
for...of是for循环首选
ES6 提供了三种不同的 for 循环。三个可用情况下，如果可以， 推荐优先使用 for-of 循环
包括我在内, 也觉得这条规则有点奇怪，但是谷歌认为它作为 for 循环的首选将会非常优雅
我认为，for...in 循环更适合对象，而 for...of 更适合数组
虽然 Google 的规范并不一定能和我们想法相吻合, 但是它依旧觉得这种做法相当优雅
不要使用eval()
不要使用 eval 或 Function(...String) 构造函数（代码加载器除外），这些功能具有潜在风险，并且在 CSP 环境中无法正常工作。
对于 eval() 而言，在 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
常量应该用大写字母和下划线表示
常量名称使用 CONSTANT_CASE: 全部为大写字母，单词用下划线分割。
如果你能确保一个变量不会再改变，你可以通过大写常量的名称来表明这一点，这使得常量的不变性在整个代码的使用中显而易见。
这个规则有个值得注意的例外是，如果常量是属于函数范围的，在这种情况下，应该将其用驼峰命名法来表示。
// 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;
使用单引号而不是双引号
普通的字符文本使用单引号（'）来分割，而不是双引号（"）
Tip: 如果一个字符串文本中包含单引号字符，请考虑使用模板字符串，而避免使用转义符号。
// 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 标准源码 ” 指南，你可以遵循这些规则，当然，很多人不同意，你可以部分遵循，甚至不遵循也可以。
我个人认为，很多情况下 Airbnb 比 Google 的规范更具吸引力，无论在何种情况下，一定要牢记，整个项目的编码风格要保持统一。
