[討論] 面試遇到的考題

[xxxx9659 (嘎嘎嘎嘎嘎)]

上個月面試一家公司出的 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://www.ptt.cc/bbs/Ajax/M.1415641238.A.B39.html
→ carylorrk: 第二題很有趣，在 C 裡面因為是 undefined behavior
→ carylorrk: 沒錯(在sequence point 前同一個變數被 expression 改
→ carylorrk: 了兩次。） 但是我記得 javascript 的標準有規定運算順
→ carylorrk: 序（由左至右），所以主管說的沒有錯。 Java 的行為也
→ carylorrk: 是。更有趣的是實際上你的是正確的，因為不是所有實作
→ carylorrk: 都符合 ECMA 標準，記得有人說過不要太依賴標準XD
→ carylorrk: 第三題空白真的很可惜，最簡單的 IIFE、jquery的優缺點
→ carylorrk: 到一些常見的 design pattern 在 JS 裡的形態
→ carylorrk: (ex:decorator、observer)都可以說。
推 carylorrk: 就算你沒有寫過像是 backbone 或 angular，大學總學過
→ carylorrk: 有掰有分數吧XDD
→ carylorrk: 至於第一題我贊同你的說法。「我認為」第一，這個效能
→ carylorrk: 不重要。第二，既然說到轉換，就應該在相同的標準（或
→ carylorrk: 說是語義）下比較。以相同語義的情況下來說，比較相同
→ carylorrk: 形態時我不覺得他們會有效能差（因比較的步驟都一樣）
→ carylorrk: 比較不同形態且需要 coercion 時說不定 == 還比較快點
→ carylorrk: 要兩者語義完全相等的情況下來比纔有意義。很重要所以
→ carylorrk: 說三遍。XD
謝謝 carylorrk 的講解

第一題 有點不懂 如果 === 兩邊型態不同 比都不用比直接 return false

       所以不管怎樣都是 === 快不是嗎??

第二題 我也用 C 的觀點去看 原來 js 標準不一樣!!!

推 mrbigmouth: 雖然==跟===的差距可能極小  但用===可以更早的突顯錯
→ mrbigmouth: 誤  不讓引擎自動做些怪事  所以能用===還是用===較好
→ mrbigmouth: 很多javascript書籍都有提到這點
→ mrbigmouth: 當a==0時 a可以是"0"可以是false可以是""
→ mrbigmouth: 這會造成日後維護程式碼的各種不方便跟誤解
→ carylorrk: 所以我們是因為語義差別，而不是效能差別才選用 ==
→ carylorrk: *才不選用 == XD
推 onininon: 這三題我大概也全錯XDDD
→ mmis1000: 一般而言只會用在 == null來偵測未定義變數吧？
→ mmis1000: 因為 == null 可以是 null 或 undefined，剛好都是空值
推 davidsky: 第一題是要考你是否習慣用===，但他的理由很怪
沒錯 沒事盡量用嚴謹的 ===

http://goo.gl/rX4wkd

看完這篇發現 只用 == 太可怕了 甚麼怪事都有

→ davidsky: 第二題我也認為沒啥意義
→ davidsky: 第三題就很重要了，不過你竟然空白...
第三題 我太弱 怕裝懂被問倒...
※ 編輯: xxxx9659 (220.129.195.251), 11/11/2014 13:43:42
→ carylorrk: 我的意思是指兩個目的一樣且預期拿到結果一樣的東西才
→ carylorrk: 能比較速度。像是在學資料結構，大家都知道 hash map
→ carylorrk: 和 rb-tree map 的差別，當你只需要 access 單 element
→ carylorrk: 時當然是 hash map 快，但是當你的需要是可以 access
→ carylorrk: 單一 elemnt，然後又可以 iterate 整個 map 並拿到排序
→ carylorrk: 過的 (key, value) pairs，那顯然就是要 tradeoff 了
→ carylorrk: 你如果用 hash map，可能就要歷遍整個 map 然後再排序
→ carylorrk: 同樣的，當你預期的結果是 x == null 的話，用 ===
→ carylorrk: 你可能需要多次比較 (undefined、NaN 等等）或是
→ carylorrk: explicit 的轉型。只有這樣的比較纔是公平的。
→ carylorrk:  == 和 === 雖然相似，但是語義上根本不同。沒有限定使
→ carylorrk: 用情景就直接問，顯然無法直接回答。
→ bndan: 其實第2題在執行上有一個小概念還不錯 @@ 由其是習慣一行程
→ bndan: 式解問題的人...
推 mmis1000: 除非就算塞在一行也不會造成語意混淆，我實在不覺得把c
→ mmis1000: ode塞在一行可以接受，每次看到那種code都讓我很想砍
→ mmis1000: 作者，別人力壓縮混淆code阿…
→ carylorrk: 推樓上，要壓縮用 grunt 就好（誤
推 oToToT: 怎麼辦我都自己寫code結果沒人看得懂，明明就很淺白啊，不
→ oToToT: 然其實有時候我也會寫太長QQ造成閱讀困難