文中的我指原文的作者
对于那些还不熟悉 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;
}
分号是必需的
每个语句必须以分号结束，禁止依靠自动分号插入。
虽然无法想象为什么会有人反对这个想法，但 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’;
});
不要使用 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’;
不鼓励 (但不禁止) 水平对齐
这种做法是允许的，但谷歌编写风格通常不鼓励这样做，甚至不需要在已经使用它的地方保持水平对齐。
水平对齐是在代码中添加可变数量的额外空格，以使某行变量的值与前面变量值对齐。
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
不要再使用 var 了
使用 const 或 let 声明所有本地变量来代替 var。默认情况下使用 const，除非需要重新分配变量在使用 let 声明。
// bad
var example = 42;
// good
let example = 42;
箭头函数是首选
箭头函数提供了简洁的语法，并解决了 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;
});
使用模板字符串而不是拼接客串
在复杂的字符串连接上使用模板字符串(用 ` 分隔)，特别是在涉及多个字符串文本时，模板字符串可以跨越多行。
// 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 允许这样做，但是如果斜杠后面有任何尾随空格，那么可能会导致一些棘手的错误，而且对读者来说不太明显。
有趣的是，谷歌和 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 环境中根本不起作用
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
常量应该用全大写字母命名，用下划线分隔
常量名称使用 CONSTANT_CASE 的格式: 所有大写字母，单词由下划线分隔。
如果您绝对确信某个变量不应该更改，那么可以通过将该常量的名称大写来表示。这使得在整个代码中使用该常量时，它的不变性非常明显。
一个值得注意的例外是，如果常量是函数作用域的。在这种情况下，应该用 camelCase 来写。
// bad
const number = 5;
// good
const NUMBER = 5;
每次声明一个变量
每个局部变量声明只声明一个变量: 声明如令 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`;
最后一个注意
正如我在开始时所说，这些不是强制要求。谷歌只是众多科技巨头之一，这些只是推荐。
也就是说，看看谷歌这样的公司提出的风格建议是很有趣的，这家公司雇佣了很多才华横溢的人，他们花了很多时间编写优秀的代码。
如果你想要遵循“符合谷歌的源代码”的指导原则，那么你可以遵循这些规则—但是，当然，许多人不同意这些规则，你可以随意忽略这些规则中的任何一个或所有规则。
我个人认为在很多情况下 Airbnb 的规范比谷歌更有吸引力。无论您对这些特定的规则采取何种立场，在编写任何类型的代码时，始终牢记风格一致性仍然很重要。
原文：13 Noteworthy Points from Google’s JavaScript Style Guide
你的点赞是我持续分享好东西的动力，欢迎点赞！
一个笨笨的码农，我的世界只能终身学习！
更多内容请关注公众号《大迁世界》