+ - ! function($) ()， function 前面的符號意思

若是在function以前加上感嘆號 (!) 會怎麼樣？好比下面的代碼： !function(){alert('iifksp')}()        // true 在控制檯運行後獲得的值時true，爲何是true這很容易理解，由於這個匿名函數沒有返回值，默認返回的就是undefined，求反的結果很天然的就是true。因此問題並不在於結果值，而是在於，爲何求反操做可以讓一個匿名函數的自調變的合法？ 平時咱們可能對添加括號來調用匿名函數的方式更爲習慣： (function(){alert('iifksp')})()        // true 或者： (function(){alert('iifksp')}())        // true   雖然上述二者括號的位置不一樣，不過效果徹底同樣。 那麼，是什麼好處使得爲數很多的人對這種歎號的方式情有獨鍾？若是隻是爲了節約一個字符未免太沒有必要了，這樣算來即便一個100K的庫恐怕也節省不了多少空間。既然不是空間，那麼就是說也許還有時間上的考量，事實很難說清，文章的最後有提到性能。 回到核心問題，爲何能這麼作？甚至更爲核心的問題是，爲何必須這麼作？ 其實不管是括號，仍是感嘆號，讓整個語句合法作的事情只有一件，就是讓一個函數聲明語句變成了一個表達式。 function a(){alert('iifksp')}        // undefined 這是一個函數聲明，若是在這麼一個聲明後直接加上括號調用，解析器天然不會理解而報錯： function a(){alert('iifksp')}()        // SyntaxError: unexpected_token   由於這樣的代碼混淆了函數聲明和函數調用，以這種方式聲明的函數a，就應該以 a(); 的方式調用。 可是括號則不一樣，它將一個函數聲明轉化成了一個表達式，解析器再也不以函數聲明的方式處理函數a，而是做爲一個函數表達式處理，也所以只有在程序執行到函數a時它才能被訪問。 因此，任何消除函數聲明和函數表達式間歧義的方法，均可以被解析器正確識別。好比： var i = function(){return 10}();        // undefined 1 && function(){return true}();        // true 1, function(){alert('iifksp')}();        // undefined 賦值，邏輯，甚至是逗號，各類操做符均可以告訴解析器，這個不是函數聲明，它是個函數表達式。而且，對函數一元運算能夠算的上是消除歧義最快的方式，感嘆號只是其中之一，若是不在意返回值，這些一元運算都是有效的： !function(){alert('iifksp')}()        // true +function(){alert('iifksp')}()        // NaN -function(){alert('iifksp')}()        // NaN ~function(){alert('iifksp')}()        // -1 甚至下面這些關鍵字，都能很好的工做： void function(){alert('iifksp')}()        // undefined new function(){alert('iifksp')}()        // Object delete function(){alert('iifksp')}()        // true   最後，括號作的事情也是同樣的，消除歧義纔是它真正的工做，而不是把函數做爲一個總體，因此不管括號括在聲明上仍是把整個函數都括在裏面，都是合法的： (function(){alert('iifksp')})()        // undefined (function(){alert('iifksp')}())        // undefined 說了這麼多，實則在說的一些都是最爲基礎的概念——語句，表達式，表達式語句，這些概念如同指針與指針變量同樣容易產生混淆。雖然這種混淆對編程無表徵影響，但倒是一塊絆腳石隨時可能由於它而頭破血流。 最後討論下性能。我在jsperf上簡單創建了一個測試：http://jsperf.com/js-funcion-expression-speed，能夠用不一樣瀏覽器訪問，運行測試查看結果。我也同時將結果羅列以下表所示（因爲我比較窮，測試配置有點丟人不過那也沒辦法：奔騰雙核1.4G，2G內存，win7企業版）： Option Code Ops/sec Chrome 13 Firefox 6 IE9 Safari 5 ! !function(){;}() 3,773,196 10,975,198 572,694 2,810,197 + +function(){;}() 21,553,847 12,135,960 572,694 1,812,238 - -function(){;}() 21,553,847 12,135,960 572,694 1,864,155 ~ ~function(){;}() 3,551,136 3,651,652 572,694 1,876,002 (1) (function(){;})() 3,914,953 12,135,960 572,694 3,025,608 (2) (function(){;}()) 4,075,201 12,135,960 572,694 3,025,608 void void function(){;}() 4,030,756 12,135,960 572,694 3,025,608 new new function(){;}() 619,606 299,100 407,104 816,903 delete delete function(){;}() 4,816,225 12,135,960 572,694 2,693,524 = var i = function(){;}() 4,984,774 12,135,960 565,982 2,602,630 && 1 && function(){;}() 5,307,200 4,393,486 572,694 2,565,645 || 0 || function(){;}() 5,000,000 4,406,035 572,694 2,490,128 & 1 & function(){;}() 4,918,209 12,135,960 572,694 1,705,551 | 1 | function(){;}() 4,859,802 12,135,960 572,694 1,612,372 ^ 1 ^ function(){;}() 4,654,916 12,135,960 572,694 1,579,778 , 1, function(){;}() 4,878,193 12,135,960 572,694 2,281,186 可見不一樣的方式產生的結果並不相同，並且，差異很大，因瀏覽器而異。 但咱們仍是能夠從中找出不少共性：new方法永遠最慢——這也是理所固然的。其它方面不少差距其實不大，但有一點能夠確定的是，感嘆號並不是最爲理想的選擇。反觀傳統的括號，在測試裏表現始終很快，在大多數狀況下比感嘆號更快——因此平時咱們經常使用的方式毫無問題，甚至能夠說是最優的。加減號在chrome表現驚人，並且在其餘瀏覽器下也廣泛很快，相比感嘆號效果更好。 固然這只是個簡單測試，不能說明問題。但有些結論是有意義的：括號和加減號最優。 可是爲何這麼多開發者鍾情於感嘆號？我以爲這只是一個習慣問題，它們之間的優劣徹底能夠忽略。一旦習慣了一種代碼風格，那麼這種約定會使得程序從混亂變得可讀。若是習慣了感嘆號，我不得不認可，它比括號有更好的可讀性。我不用在閱讀時留意括號的匹配，也不用在編寫時粗心遺忘——