声明数组大小有很多可感知的好处,但我认为大多数可感知的好处只是被传递的 FUD。
性能更好!/速度更快!
据我所知,预分配和动态分配之间的区别可以忽略不计。
更有趣的是,规范确实not声明数组应该设置为预先分配的长度!
来自第 15.4.2.2 节ECMA-262 http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf:
如果论证len是一个数字并且 ToUint32(len) 等于len,那么length新构造的对象的属性设置为 ToUint32(len)。如果论证len是一个数字并且 ToUint32(len) 不等于len, a 范围误差抛出异常。
一个不科学的娱乐测试用例如下:http://jsbin.com/izini http://jsbin.com/izini
它使代码更容易理解!
就我个人而言,我不同意。
考虑一下您过去编写的 JavaScript,并考虑您将来可能需要编写的代码。我想不出有哪一次需要对我的数组之一指定静态限制。我还认为,在 javascript 中限制数组的潜在问题远远超过了让人们知道你在想什么而不进行实际检查所带来的好处。让我们权衡一下利弊...
Pros:
- 他们会更容易理解您想要代码做什么。
- 他们稍后将能够找到由你的假设引起的错误(开玩笑)
Cons:
- 快速浏览很容易将“new Array(10)”与“new Array('10')”混淆,它们执行完全不同的操作!
- 您对代码施加了任意限制,没有正常的长度限制,导致您编写大量样板代码来检查和维护限制。
- 您对代码施加了任意限制,这些限制可能已推广到可以处理任何长度的值。
- 您正在假设人们将如何阅读您的代码,同时假设替代方案不会那么混乱。
你也可能写过:
//I assume this array will always be length 10
var arr = new Array();
在上述情况下,评论甚至可能更好。显式的意图声明可以避免不习惯使用构造函数作为意图声明的任何混淆。
那么好吧..为什么你认为它还在那里?
方便。当他们编写规范时,我认为他们意识到了两件事。
- 来自类似语言的开发人员会习惯这种分配。
- ECMAScript 的实现可能会使用它来提高性能。
所以他们把它放在那里。
规范仅定义了参数的使用,而没有定义它应该如何实现。