Google JavaScript 风格指南的13个要点

@sakila1012 2018-04-03 02:41:28发表于 sakila1012/blog

原文链接

对于那些还不是很熟悉 JavaScript 的人,Google 提供了一套编写 JavaScript 风格的指南,列出了(Google认为)编写整齐、可理解代码的最佳实践风格。

这些并不是编写有效 JavaScript 的硬性规范和快速规范,只有在您的源文件中使得样式保持一致性和吸引人选择。对于 JavaScript 而言,这一点特别有趣,因为 JavaScript 是一个灵活且包容的语言,它允许各种文体选择。

谷歌(Google)和 Airbnb 有两款最受欢迎的风格指南。如果您花了大量的时间编写 JS,我建议您查看它们。

下面是 13 个我认为是来自谷歌的 JS 风格指南最有趣和最有意义的规范。

他们处理所有来自激烈争论的问题(标签和空格,以及分号应该如何使用的争议问题),以及一些令我惊讶,但晦涩难懂的规范。他们肯定会改变我写的我的 JS 的方式。

对于每条规范,我将简要介绍,然后是详细描述该规范的样式指南中的辅助引号。在适用的情况下,我还将提供一个样式示例实践,并将其与不遵循规范的代码进行对比。

使用空格,而不是制表符(tab)

除了行结束符序列外,ASCII 水平空格字符(0x20)是源文件中出现的唯一空白字符。这意味着…制表符不用于缩进。
指南稍后指定您应该使用两个空格(而不是4个)来缩进。

// 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模块(即导出和导入关键字),因为它们的语义尚未确定。请注意,一旦语义完全标准化,将重新讨论此策略。

// Don't do this kind of thing yet:
//------ 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声明所有局部变量。默认情况下使用Const,除非需要重新分配变量。不能使用var关键字。
我仍然看到人们在StackOverflow和其他地方的代码示例中使用var。我不知道是否有人会为它辩护,或者这只是一种旧习惯的消亡。

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

箭头函数优先

箭头函数提供了简洁的语法,并解决了许多困难。更喜欢箭头函数而不是函数关键字,特别是对于嵌套函数。

老实说,我只是觉得箭头函数很棒,因为它们更简洁,看上去更好。结果他们也起到了非常重要的作用。

使用模板字符串而不是串联

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

// 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的规范)。

虽然Google建议连接更长的字符串(如下所示),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 或函数(... string)构造函数(代码加载器除外)。这些特性可能是危险的,而且简单地不能在csp 环境中工作。

eval() 的 MDN 页面中甚至有一个名为“Don‘t use 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;

每个声明中的一个变量

每个局部变量声明只声明一个变量:不使用像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`;

最后一个要点

正如我刚开始说的那样,这些不是任务授权。谷歌只是许多科技巨头之一,而这些只是建议。

这就是说,很有意思的是,看看谷歌这样的公司提出的风格建议,它雇佣了很多优秀的人,他们花了很多时间写优秀的代码。

如果你想遵循“谷歌兼容源代码” - 的指导方针,你可以遵循这些规则,但是,当然,很多人不同意,你可以随意忽略这一切。

我个人认为,在很多情况下,Airbnb的规范比谷歌的更有吸引力。无论您对这些特定规则采取了什么立场,在编写任何代码时保持风格一致性仍然很重要。