谷歌JavaScript编程风格指导中的13个值得关注的要点

编者按:谷歌的程序员大大为了帮助刚入手JavaScript的小白们写出干净、易懂的代码,提供了一个独具特色的教程《Java Script指南》,而本文作者丹尼尔西蒙斯,一位web开发人员/Java爱好者精心总结了谷歌推出的这份指南中最有趣、最有用的十三条规则。

JS具有强大的灵活性和包容性,因此,JS的编写具有不同的风格,因此如何保证你的源程序在编写过程中保持着统一的风格才是编写JS的过程中需要注意的。

谷歌和Airbnb使用着两种最流行的编写规则,它们对细节的把控深深的影响着我,从一个个的标点到页面的布局,扣着一个个的小细节,这也深深的影响了我在码JS过程中的一些习惯。以下是我挑选的谷歌JS指南中最有趣、有用的十三条规则。

我将针对每一个规则都会给一个总体的叙述,然后再进行详细的叙述,结合自身的开发经历,给出一些实用的介绍,如果条件允许,还有一些相关的例子给大家分享一下。

用空格还是用Tab键?

除了行终止符之外,ASCII字符(0x20)是在源文件中出现的唯一空白字符。这意味着Tab制表符不用于缩进。

因此,你应该使用空格来实现你的设计而不是Tab制表符,而且只要键入两个空格就可以,而不是四个空格。

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

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

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

必不可少的分号

每个语句都必须以分号结束。不要为了省事使用自动分号插入。那会给你带来后面很多不必要的麻烦的。

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

虽然我无法想象为什么有人反对这个想法,但在JS中使用分号正在成为一种新的“空格与制表符”的争论。谷歌是支持使用分号的,至于刚入行的小白还是建议跟着潮流走。

不要使用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型。我不知道其他人使用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允许这样做,但如果在斜杠之后出现任何尾随空格,那么它就会导致棘手的错误,而且对新手来说不太明显。

// 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.’;

有趣的是,这是谷歌和Airbnb意见不同的规则(这是Airbnb的规范)。虽然谷歌推荐连接更长的字符串(如下所示),但Airbnb的风格指南建议基本上什么都不做,并且允许长字符串在需要的时候继续使用。

“for…of”是“for循环”的首选类型

在ES6中,语言现在有三种不同的for循环。程序员是可以使用所有的循环,但在可能的情况下应该首选for-of循环。

我个人感觉for更适合于对象,而for of更适合于数组。只是适合不同的风格。虽然谷歌的规范并不一定与这个想法相矛盾,但是,可以看出谷歌对于这个循环还是情有独钟的。

不要使用eval()

不要使用eval或函数(…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
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的规范比谷歌更有吸引力。不过无论对这些特定的规则采取何种立场,我们在编写任何类型的代码时,唯一的要求就是要保持风格上的一致性。

本文文字及图片出自 36氪

余下全文(1/3)
分享这篇文章:

请关注我们:

共有 1 条讨论

  1. 林学开  这篇文章, 并对这篇文章的反应是垃圾

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注