JavaScript 规范(三)-前端编码风格
接上一篇:
eval 函数(魔鬼)
eval()
不但混淆语境还很危险,总会有比这更好、更清晰、更安全的另一种方案来写你的代码,因此尽量不要使用 evil 函数。
this 关键字
只在对象构造器、方法和在设定的闭包中使用 this
关键字。this 的语义在此有些误导。它时而指向全局对象(大多数时),时而指向调用者的定义域(在 eval 中),时而指向 DOM 树中的某一节点(当用事件处理绑定到 HTML 属性上时),时而指向一个新创建的对象(在构造器中),还时而指向其它的一些对象(如果函数被 call()
和 apply()
执行和调用时)。
正因为它是如此容易地被搞错,请限制它的使用场景:
在构造函数中
在对象的方法中(包括由此创建出的闭包内)
首选函数式风格
函数式编程让你可以简化代码并缩减维护成本,因为它容易复用,又适当地解耦和更少的依赖。
接下来的例子中,在一组数字求和的同一问题上,比较了两种解决方案。第一个例子是经典的程序处理,而第二个例子则是采用了函数式编程和 ECMA Script 5.1 的数组方法。
例外:往往在重代码性能轻代码维护的情况之下,要选择最优性能的解决方案而非维护性高的方案(比如用简单的循环语句代替 forEach)。
不推荐
推荐
另一个例子通过某一规则对一个数组进行过滤匹配来创建一个新的数组。
不推荐
推荐
使用 ECMA Script 5
建议使用 ECMA Script 5 中新增的语法糖和函数。这将简化你的程序,并让你的代码更加灵活和可复用。
数组和对象的属性迭代
用 ECMA5 的迭代方法来迭代数组。使用 Array.forEach
或者如果你要在特殊场合下中断迭代,那就用Array.every
。
数组和对象字面量
用数组和对象字面量来代替数组和对象构造器。数组构造器很容易让人在它的参数上犯错。
不推荐
正因如此,如果将代码传参从两个变为一个,那数组很有可能发生意料不到的长度变化。为避免此类怪异状况,请总是采用更多可读的数组字面量。
推荐
对象构造器不会有类似的问题,但是为了可读性和统一性,我们应该使用对象字面量。
不推荐
应该写成这样:
推荐
修改内建对象的原型链
修改内建的诸如 Object.prototype 和 Array.prototype 是被严厉禁止的。修改其它的内建对象比如Function.prototype,虽危害没那么大,但始终还是会导致在开发过程中难以 debug 的问题,应当也要避免。
自定义 toString() 方法
你可以通过自定义 toString()
来控制对象字符串化。这很好,但你必须保证你的方法总是成功并不会有其它副作用。如果你的方法达不到这样的标准,那将会引发严重的问题。如果 toString()
调用了一个方法,这个方法做了一个断言3 ,当断言失败,它可能会输出它所在对象的名称,当然对象也需要调用toString()
。
圆括号
一般在语法和语义上真正需要时才谨慎地使用圆括号。不要用在一元操作符上,例如delete
, typeof
和void
,或在关键字之后,例如 return
, throw
, case
, new
等。
字符串
统一使用单引号(’),不使用双引号(“)。这在创建 HTML 字符串非常有好处:
三元条件判断(if 的快捷方法)
用三元操作符分配或返回语句。在比较简单的情况下使用,避免在复杂的情况下使用。没人愿意用 10 行三元操作符把自己的脑子绕晕。
不推荐
推荐
好了,JavaScript 规范更新完成,后续会继续更新前端编码的一般规范和HTML规范,让每一位前端er的编码都规范起来,让我们朝着前端大牛看齐。