作者xxxx9659 (嘎嘎嘎嘎嘎)
看板Ajax
标题[讨论] 面试遇到的考题
时间Tue Nov 11 01:40:35 2014
上个月面试一家公司出的 javascript 考题
其中有几题很有趣 列出来跟大家讨论
1. === 跟 == 这两个运算元谁比较快？
a. === 快
b. == 快
c. 一样快
d. 不一定 看状况
我写 a
但是後面注解
//有人在管 js 的低阶运算效能吗??!! 根本一样快吧...
後来主管说服我说 == 要多做一次形态转换 所以比较慢
2.
var ary = [];
for(var i = 0; i < 10; ary[i++] = i);
alert(ary); //显示为何？
a. 0,1,2,3,4,5,6,7,8,9
b. 1,2,3,4,5,6,7,8,9,10
c. 语法错误 当掉
d. 不一定 看状况
这题我写 a
但我後面注解
//实际上这是 "未定义行为" 任何後果都有可能 要看js引擎的实作
但是主管很肯定答案是 b
他觉得 i++ 先取值再+1 而且取完值後 一定在中括号内就作完 +1 的动作
3. 写出你有用过的 pattern 跟 framework 并简单介绍
这题我空白...
虽然主管只是想测试我反应 考试答案正不正确不是重点
但是我还是想知道 这几题有没有更好更正统的解释？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.133.153.169
※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Ajax/M.1415641238.A.B39.html
1F：→ carylorrk: 第二题很有趣，在 C 里面因为是 undefined behavior 11/11 07:58
2F：→ carylorrk: 没错(在sequence point 前同一个变数被 expression 改 11/11 08:00
3F：→ carylorrk: 了两次。） 但是我记得 javascript 的标准有规定运算顺 11/11 08:00
4F：→ carylorrk: 序（由左至右），所以主管说的没有错。 Java 的行为也 11/11 08:01
5F：→ carylorrk: 是。更有趣的是实际上你的是正确的，因为不是所有实作 11/11 08:02
6F：→ carylorrk: 都符合 ECMA 标准，记得有人说过不要太依赖标准XD 11/11 08:03
7F：→ carylorrk: 第三题空白真的很可惜，最简单的 IIFE、jquery的优缺点 11/11 08:06
8F：→ carylorrk: 到一些常见的 design pattern 在 JS 里的形态 11/11 08:06
9F：→ carylorrk: (ex:decorator、observer)都可以说。 11/11 08:08
10F：推 carylorrk: 就算你没有写过像是 backbone 或 angular，大学总学过 11/11 08:14
11F：→ carylorrk: 有掰有分数吧XDD 11/11 08:14
12F：→ carylorrk: 至於第一题我赞同你的说法。「我认为」第一，这个效能 11/11 08:15
13F：→ carylorrk: 不重要。第二，既然说到转换，就应该在相同的标准（或 11/11 08:17
14F：→ carylorrk: 说是语义）下比较。以相同语义的情况下来说，比较相同 11/11 08:17
15F：→ carylorrk: 形态时我不觉得他们会有效能差（因比较的步骤都一样） 11/11 08:18
16F：→ carylorrk: 比较不同形态且需要 coercion 时说不定 == 还比较快点 11/11 08:21
17F：→ carylorrk: 要两者语义完全相等的情况下来比才有意义。很重要所以 11/11 08:23
18F：→ carylorrk: 说三遍。XD 11/11 08:23
谢谢 carylorrk 的讲解
第一题 有点不懂 如果 === 两边型态不同 比都不用比直接 return false
所以不管怎样都是 === 快不是吗??
第二题 我也用 C 的观点去看 原来 js 标准不一样!!!
19F：推 mrbigmouth: 虽然==跟===的差距可能极小 但用===可以更早的突显错 11/11 09:11
20F：→ mrbigmouth: 误 不让引擎自动做些怪事 所以能用===还是用===较好 11/11 09:12
21F：→ mrbigmouth: 很多javascript书籍都有提到这点 11/11 09:12
22F：→ mrbigmouth: 当a==0时 a可以是"0"可以是false可以是"" 11/11 09:15
23F：→ mrbigmouth: 这会造成日後维护程式码的各种不方便跟误解 11/11 09:16
24F：→ carylorrk: 所以我们是因为语义差别，而不是效能差别才选用 == 11/11 10:48
25F：→ carylorrk: *才不选用 == XD 11/11 10:48
26F：推 onininon: 这三题我大概也全错XDDD 11/11 11:26
27F：→ mmis1000: 一般而言只会用在 == null来侦测未定义变数吧？ 11/11 11:33
28F：→ mmis1000: 因为 == null 可以是 null 或 undefined，刚好都是空值 11/11 11:34
29F：推 davidsky: 第一题是要考你是否习惯用===，但他的理由很怪 11/11 11:52
没错 没事尽量用严谨的 ===
http://goo.gl/rX4wkd
看完这篇发现 只用 == 太可怕了 甚麽怪事都有
30F：→ davidsky: 第二题我也认为没啥意义 11/11 11:53
31F：→ davidsky: 第三题就很重要了，不过你竟然空白... 11/11 11:53
第三题 我太弱 怕装懂被问倒...
※ 编辑: xxxx9659 (220.129.195.251), 11/11/2014 13:43:42
32F：→ carylorrk: 我的意思是指两个目的一样且预期拿到结果一样的东西才 11/11 14:34
33F：→ carylorrk: 能比较速度。像是在学资料结构，大家都知道 hash map 11/11 14:35
34F：→ carylorrk: 和 rb-tree map 的差别，当你只需要 access 单 element 11/11 14:37
35F：→ carylorrk: 时当然是 hash map 快，但是当你的需要是可以 access 11/11 14:38
36F：→ carylorrk: 单一 elemnt，然後又可以 iterate 整个 map 并拿到排序 11/11 14:38
37F：→ carylorrk: 过的 (key, value) pairs，那显然就是要 tradeoff 了 11/11 14:39
38F：→ carylorrk: 你如果用 hash map，可能就要历遍整个 map 然後再排序 11/11 14:40
39F：→ carylorrk: 同样的，当你预期的结果是 x == null 的话，用 === 11/11 14:41
40F：→ carylorrk: 你可能需要多次比较 (undefined、NaN 等等）或是 11/11 14:42
41F：→ carylorrk: explicit 的转型。只有这样的比较才是公平的。 11/11 14:42
42F：→ carylorrk: == 和 === 虽然相似，但是语义上根本不同。没有限定使 11/11 14:45
43F：→ carylorrk: 用情景就直接问，显然无法直接回答。 11/11 14:46
44F：→ bndan: 其实第2题在执行上有一个小概念还不错 @@ 由其是习惯一行程 11/11 18:38
45F：→ bndan: 式解问题的人... 11/11 18:38
46F：推 mmis1000: 除非就算塞在一行也不会造成语意混淆，我实在不觉得把c 11/11 19:11
47F：→ mmis1000: ode塞在一行可以接受，每次看到那种code都让我很想砍 11/11 19:11
48F：→ mmis1000: 作者，别人力压缩混淆code阿… 11/11 19:11
49F：→ carylorrk: 推楼上，要压缩用 grunt 就好（误 11/12 09:28
50F：推 oToToT: 怎麽办我都自己写code结果没人看得懂，明明就很浅白啊，不 11/13 22:19
51F：→ oToToT: 然其实有时候我也会写太长QQ造成阅读困难 11/13 22:20