[討論] 面試遇到的考題

作者: xxxx9659 (嘎嘎嘎嘎嘎)   2014-11-11 01:40:35
上個月面試一家公司出的 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 並簡單介紹
這題我空白...
雖然主管只是想測試我反應 考試答案正不正確不是重點
但是我還是想知道 這幾題有沒有更好更正統的解釋?
作者: carylorrk (carylorrk)   2014-11-11 07:58:00
第二題很有趣,在 C 裡面因為是 undefined behavior沒錯(在sequence point 前同一個變數被 expression 改了兩次。) 但是我記得 javascript 的標準有規定運算順序(由左至右),所以主管說的沒有錯。 Java 的行為也是。更有趣的是實際上你的是正確的,因為不是所有實作都符合 ECMA 標準,記得有人說過不要太依賴標準XD第三題空白真的很可惜,最簡單的 IIFE、jquery的優缺點到一些常見的 design pattern 在 JS 裡的形態(ex:decorator、observer)都可以說。就算你沒有寫過像是 backbone 或 angular,大學總學過有掰有分數吧XDD至於第一題我贊同你的說法。「我認為」第一,這個效能不重要。第二,既然說到轉換,就應該在相同的標準(或說是語義)下比較。以相同語義的情況下來說,比較相同形態時我不覺得他們會有效能差(因比較的步驟都一樣)比較不同形態且需要 coercion 時說不定 == 還比較快點要兩者語義完全相等的情況下來比纔有意義。很重要所以說三遍。XD
作者: mrbigmouth (大嘴先生)   2014-11-11 09:11:00
雖然==跟===的差距可能極小 但用===可以更早的突顯錯誤 不讓引擎自動做些怪事 所以能用===還是用===較好很多javascript書籍都有提到這點當a==0時 a可以是"0"可以是false可以是""這會造成日後維護程式碼的各種不方便跟誤解
作者: carylorrk (carylorrk)   2014-11-11 10:48:00
所以我們是因為語義差別,而不是效能差別才選用 ==*才不選用 == XD
作者: onininon (萬)   2014-11-11 11:26:00
這三題我大概也全錯XDDD
作者: mmis1000 (秋月戀楓)   2014-11-11 11:33:00
一般而言只會用在 == null來偵測未定義變數吧?因為 == null 可以是 null 或 undefined,剛好都是空值
作者: davidsky (Alive)   2014-11-11 11:52:00
第一題是要考你是否習慣用===,但他的理由很怪第二題我也認為沒啥意義第三題就很重要了,不過你竟然空白...
作者: carylorrk (carylorrk)   2014-11-11 14:34:00
我的意思是指兩個目的一樣且預期拿到結果一樣的東西才能比較速度。像是在學資料結構,大家都知道 hash map和 rb-tree map 的差別,當你只需要 access 單 element時當然是 hash map 快,但是當你的需要是可以 access單一 elemnt,然後又可以 iterate 整個 map 並拿到排序過的 (key, value) pairs,那顯然就是要 tradeoff 了你如果用 hash map,可能就要歷遍整個 map 然後再排序同樣的,當你預期的結果是 x == null 的話,用 ===你可能需要多次比較 (undefined、NaN 等等)或是explicit 的轉型。只有這樣的比較纔是公平的。== 和 === 雖然相似,但是語義上根本不同。沒有限定使用情景就直接問,顯然無法直接回答。
作者: bndan (seed)   2014-11-11 18:38:00
其實第2題在執行上有一個小概念還不錯 @@ 由其是習慣一行程式解問題的人...
作者: mmis1000 (秋月戀楓)   2014-11-11 19:11:00
除非就算塞在一行也不會造成語意混淆,我實在不覺得把code塞在一行可以接受,每次看到那種code都讓我很想砍作者,別人力壓縮混淆code阿…
作者: carylorrk (carylorrk)   2014-11-12 09:28:00
推樓上,要壓縮用 grunt 就好(誤
作者: oToToT (屁孩)   2014-11-13 22:19:00
怎麼辦我都自己寫code結果沒人看得懂,明明就很淺白啊,不然其實有時候我也會寫太長QQ造成閱讀困難

Links booklink

Contact Us: admin [ a t ] ucptt.com