[译] Google JavaScript 风格指南中 13 个值得注意的细节
栏目: JavaScript · 发布时间: 6年前
内容简介:原文地址:原文作者:Daniel Simmons译者:命名最头疼
原文地址: 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 的规范更具吸引力,无论在何种情况下,一定要牢记,整个项目的编码风格要保持统一。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Data Mining
Jiawei Han、Micheline Kamber、Jian Pei / Morgan Kaufmann / 2011-7-6 / USD 74.95
The increasing volume of data in modern business and science calls for more complex and sophisticated tools. Although advances in data mining technology have made extensive data collection much easier......一起来看看 《Data Mining》 这本书的介绍吧!