匿名函数的写法January 3, 2010
这是 小马 在交流会中的分享，可能有些朋友还不曾了解，同时也为了自己温故而知新，就整理下。
多种方式
可以想像得到，有很多方法立即执行匿名函数，简单的整理就有下面三种的典型方式（还有其他方式的，欢迎告知）：
方式一
(function() {
// …
})();方式二
void function() {
// …
}();方式三
~function() {
// …
}();方式一 和 方式二 大家可能都看到过，这里主要说明下 方式三。在说明 方式三 之前，我们现回顾下运算符“~”（位取反）在 EMCAScript 中的定义（第五版的第 72 页），简单的翻译下:
- 按运算符结合语句
- 将旧值转换为 32 位整型
- 执行运算符后的语句
- 转换之行结果为 32 位整形并返回
从上面可以了解，其实位运算符都能立即返回后面表达式的值。其实其他位运算符都可以达到这样的目的，例如
!function() {
// …
}();等都可以达到我们的目的。所以其实用“~”也并无其他的原因，仅仅是代码“看着好看”而已 :^)
效率
与其说三种方式执行匿名函数的效率，到不如直接分析个运算符的执行效率。那么我们对比再来看看“()”以及“void”在 EMCA 规范中的定义
组运算符（第五版 66 页）
- 返回表达式的执行结果
void（第五版 70 页）
- 按运算符结合语句
- 执行
- 返回 undefined
由于组运算符还需要执行语句并返回语句块返回的值，对比 void 会多个获取语句块的操作（虽然消耗不了多少的性能），因此在这种情况下 void 的性能要优于组运算符。
对比两者，那么 方式三 的性能对比很明显要低于前两者。总结起来就是光从语法的角度上分析，在上面三者匿名函数的方式中 方式二 优于 方式一，方式三 的效率最低。
总结
思考下三者之间的优异
- 方式一的写法很常见而且很保险，所以并不会有人因为你使用这种方式而责怪你
- 但使用方式一的同学，可能经常会犯忘记匹配括号的“毛病”（特别是语句块很长时，就经常搞错）
- 使用位运算符执行匿名函数很新潮，用来装
逼酷不错
- 很多 IDE （如 IDEA）以及语法高亮工具不支持 方式三 的写法
- void 效率最好，但总感觉相比其他两种实现方式非常的臃肿（仅仅多几个字符？）
那么
- 综合代码量以及效率等情况考虑，用 方式一 没错的
- 在需要额外节省代码的极端情况，用 方式三
- 考虑效率优先，那么使用 方式二
这里要说明下，其实三种方式效率之间的差异非常小。因此单纯拿效率来考虑采用那种方式，几乎是站不住脚的。
具体采用何种方案，需要根据实际情况来考虑。比如我自己，经常会使用方式三，是因为 1、方便（加一个字符即可） 2、在函数长的情况下匹配括号会很头晕 3、用起来很酷，但 方式三 会经常让看我代码的组员感到困扰。
如果在些类库等框架性质的基础代码，用 方式一 最保险同时大家都容易看懂，是最保险的选择。
附
看见 阮一峰 的 Blog 上有篇文章说避免使用 void 运算符。其实在 Javascript 中， void 的使用方面还是比较常见的。
例如，我们会强制让某些调用返回 undefined 以阻止浏览器等默认行为（我们经常看到的就比如很多 Javascript Bookmark 前面就经常会加上 void 运算符）。
所以，还是“物尽其用”吧。
-- EOF --
又从 James Padolsey 这里得到个好的点子。
在实际写脚本过程中可能有段 Javascript 和 HTML 非常相关（比如实例化 Slider 等这样组件），那么通常我们会将它紧放到 HTML 的后面。
“传统”的做法需要顾虑的点有很多。因为脚本是立即被执行的，所以要考虑例如调用的组件是否已经声明，以及如果有 Ajax 请求是否会堵死浏览器等等。
下面的代码就是本篇 Blog 提供的另个思路，但愿我看起来不是那么的火星：
<div id="some-div">
<script type=":contextual">
alert(this.id); // "some-div" is alerted
</script>
</div>原文作者的想法是改变 script 标签的 this 指向到父节点的 Element，从而关联上下文 HTML 结构。
看它的实现代码：
<script type="text/javascript">
~function() {
var scripts = document.getElementsByTagName('script'),
script, i = 0;
while ((script = scripts[i++])) {
if (/:contextual$/.test(script.type)) {
(new Function(script.innerHTML)).call(script.parentNode);
}
}
}();
</script>不过如原作者所说的外，其实还有很多顺带的好处
- 将 this 指向关联到父节点，遍历查找 DOM 非常的方便
- 相关的 script 标签和 HTML 结合紧密，很清楚就能明白这段脚本需要做什么
- 统一调用，可以考虑懒加载
- 方便复制粘贴 :^)
当然，上面的代码仅仅是个想法而已，在实际编码中还需谨慎应用。滥用此方法可以预料到的 些问题，比如：
- 脚本执行顺序改变
- 弄乱作用域，如果你的代码严重依赖 this ，那么将会是个噩梦（当然，这本身也不是个好习惯）
- 让不了解此机制的其他开发者迷惑
正如原作者所言，在我们写代码的时候能“Thinking outside the box”，那才是最重要的 :^)
-- EOF --
Javascript 选择器（selector engine）似乎从 jQuery 流行以来就大行其道，改变了原有 Javascript 选择 DOM 节点的方式。
目前 Javascript 选择器也有众多的选择，包括能列举出来的就有 Peppy、 Sizzle 以及 Sly 等，它们都实现了所有的 CSS3 选择器并且性能不俗。
而此次特别要推荐 Mini 的因素有很多。其最大的亮点就是从实用主义出发，简单高效的完成任务。
实用主义
jQuery 的作者 John Resig 曾经统计 jQuery 框架常用的几个选择器。 很惊讶的发现用户其实常用 tagName、className 以及 id 就能完成 95% 以上的工作。
而 Mini 就从实用出发，它并没有标榜自己实现了全部 CSS3 的所有选择器，只是实现了下面的选择器及其变种：
- div
- .example
- body div
- div, p
- div, p, .example
- div p
- div > p
- div.example
- ul .example
- #title
- h1#title
- div #title
- ul.foo > * span
是的，虽然不多，但是相信在日常中已经足够使用。
实用主义虽然让 Mini 提供的功能有限，但从个侧面带来的优势就是 性能方面非常的理想。 当然这还有与它的内部实现有关。
简单至上
Mini 的代码很简单，甚至不用恐惧于如何去读懂 Sizzle 这样的每行源代码。先从它的调用函数 _find 看起，往下阅读几行，你就发现它性能的秘密
if (!simple && context.querySelectorAll) {
return realArray(context.querySelectorAll(selector));
}很多的现代浏览器（包括 Gecko、WebKit 等）都 提供了原生的 Javascript 选择器支持。 Mini 充分得利用了这点，从而将大部分的工作交给了浏览器（也免除了日后的维护之忧）。这点非常值得称道， 也是我们以后写 Javascript 应该走的方向 -- 要基于浏览器提供的功能而非类型进行对应的开发。
_find 其后的逻辑非常的简单，使用几个正则将提供的选择器解析出来，分别根据 getElementsByClassName、 getElementsByClassName 以及 getElementById 获取节点。
继续根据上面的思路，由于陈旧的 IE 没有既没有提供 querySelectorAll 也没有提供 getElementsByClassName， 那么它只能走到 else 的尽头，使用 filterByAttr 函数。
取到对应 className 以及 tagName 后，还得根据选择器获取其与其相符的节点，那么就轮到 filterParents 干活了。
filterParents 这个函数也是相对 _find 比较核心的函数，而且也是主要的性能消耗点。filterParents 其实要做的和 _find 类似，唯一不同的是它根据关系符向上剔除未满足条件的节点。
通过上面两个函数所得到的节点，通常已经是满足选择符条件的节点了。 但是可能的情况就是有重复的节点，这时就该 unique 函数上场，顾名思义剔除重复的节点。
这里要提到的就是 unique 函数做了个简单的 memoization 实现， 作者的用心可谓从细节方面体现得淋漓尽致。还有个小技巧就是
var uid = +new Date();
竟然可以用这样直接返回时间戳，俏皮的代码让人再次感到犹如嚼了口薄荷糖，非常的清新（好吧，我火星了）。
读码到最后，有一点思考就是为何每次都要使用 realArray 函数强制将 NodeList 转换成 Array？虽然使用 querySelectorAll 返回的是 NodeList ，但是也是可以使用 Array 操作迭代。作者这样的做法我推测，可能是出于返回数据类型一致的缘故。
观点
说说到我的个人观点，这可能会让这篇文章前后矛盾。Javascript 选择器（selector engine）我个人不是非常推荐使用。
原因主要有两点，其一就是性能，其二就是会让写出来的代码过于的依赖于 DOM 结构。但能读到如 Mini 这样的代码，窥其内部运作机制，未尝不是件非常让人愉悦的事情。
最后，说说 Mini 的作者 James Padolsey 。我本人也很难相信，他竟然只有 19 岁！更难 得的是在他 Blog 上的 About me 页面中写道
What services do I currently offer?
- Everything JavaScript!
同时，他也是 jQuery Cookbook 的作者。 “小小年纪”能够有这样的心态以及成就，让我们这帮“前端老古董”感到唏嘘不已 :^)
附
Bang 兄已对 Mini 的代码做了更为详尽的解析，有兴趣的可以参看他的相关 Blog。
- «
- 1
- 2
- 3
- 4
- 5
- 6
- ...
- 25
- »
