全球支配，第二部分
2008年4月16日在下午1時29分由Douglas Crockford |在發展 | 9評論我繼續練習的工藝編程，我總是檢查我的做法。 我可以提高我的使用模式，這樣我可以讓我的程序更清晰，更強大，更好？ 這是特別重要的工作時用的語言如JavaScript其中有一個偏見有利於模式的混亂，弱，差。
其中最嚴重的特點是它依賴 JavaScript的全局變量。 這可以緩解與全球減排和模塊的模式 ，這樣可以大大減少數量的全局變量，我們需要聲明。
但是，當我們必須聲明一個全局變量，如何辦呢？ JavaScript提供了三種方法聲明一個全局變量，它們都有問題。 這是最最差的？
首先是分配給一個新的名字以外的任何功能。
可惜= {} / /第一種形式 二是使用var關鍵字以外的任何功能。
VAR可惜= {} / /第二種形式 三是分配給屬性的全局對象。
this.pity = {} / /第三種形式 所有三種形式做同樣的事情。 （還有第四個方式，惡劣暗示全球性的，但我們不會說話的，在這裡，並且不要讓我開始在第五和第六的方法。）
因此，考慮三種方式做同樣的事情，我們應該使用它？ 以前我贊成第二種方式。 它看起來對我最清楚的說明（或至少暗示）我打算申報的東西。
但它並不完全令人滿意。 首先，有些人看var在那個位置的聲明變量的範圍的編譯單元，類似的方式static作品在C這將是一個有益的閱讀，除了JavaScript沒有編譯單元的範圍。 一個有經驗的程序員應該知道，但以驚人的比例Web開發人員計劃在無知的語言，所以這是一個溫和的關注。
一個更令人關注的是，第二種形式是大於第一種形式，但做同樣的事情。 一般來說，我更喜歡最小的形式。
但是，事情終於說服了我的第一種形式是最糟糕的是，IE得到錯誤的第二種形式，使負責任自適應方案失敗時使用構造像
VAR可惜= this.pity | | {}; 為了能夠最大限度地生產，我想避免的功能，具有便攜性的問題。 我花了很長時間接受的是，第二種形式是有問題的，因此應避免。
我最喜歡對第二種形式是，它似乎更有意的。 通過輸入var ，我宣布，這不是一個偶然的拼寫錯誤。 我故意宣布一個新的全局變量。 但JavaScript放在眼裡。 我仍然覺得有必要指出的意圖，所以我在註釋狀態。
/ *全球可惜* / 可惜= {};
JSLint是能夠理解的註釋，可以提醒我任何全局變量，我沒有故意申報。 這給了我信心，我不是一個常見的錯誤。 第二種形式讓我感覺很好，但實際上並沒有給我任何真正的保證。
我仍然在學習如何編程。 我讀的代碼，我認為意見的其他程序員。 我仍然有能力改變我的做法。 這是很難承認，有時我以前的做法是薄弱。 但是，這足以抵消採用的做法是強。
共享和擴展： 書籤與del.icio.us | Digg它！ | 書籤交易！
9評論
對不起，評論已關閉在這個時候。
YUI庫在Twitter
克羅克福德於 JavaScript視頻系列
翻譯
最近的帖子
檔案：
- 2011年7月 （7）
- 2011年6月 （8）
- 2011年5月 （6）
- 2011年4月 （10）
- 2011年3月 （8）
- 2011年2月 （5）
- 2011年1月 （10）
- 2010年12月 （24）
- 2010年11月 （21）
- 2010年10月 （11）
- 2010年9月 （17）
- 2010年8月 （18）
- 2010年7月 （8）
- 2010年6月 （11）
- 2010年5月 （11）
- 2010年4月 （22）
- 2010年3月 （22）
- 2010年2月 （16）
- 2010年1月 （8）
- 2009年12月 （9）
- 2009年11月 （29）
- 2009年10月 （14）
- 2009年9月 （12）
- 2009年8月 （4）
- 2009年7月 （5）
- 2009年6月 （7）
- 2009年5月 （7）
- 2009年4月 （7）
- 2009年3月 （15）
- 2009年2月 （10）
- 2009年1月 （7）
- 2008年12月 （11）
- 2008年11月 （12）
- 2008年10月 （16）
- 2008年9月 （4）
- 2008年8月 （9）
- 2008年7月 （12）
- 2008年6月 （11）
- 2008年5月 （12）
- 2008年4月 （11）
- 2008年3月 （7）
- 2008年2月 （10）
- 2008年1月 （6）
- 2007年12月 （12）
- 2007年11月 （6）
- 2007年10月 （5）
- 2007年9月 （8）
- 2007年8月 （6）
- 2007年7月 （3）
- 2007年6月 （7）
- 2007年5月 （12）
- 2007年4月 （8）
- 2007年3月 （7）
- 2007年2月 （7）
- 2007年1月 （8）
- 2006年12月 （5）
- 2006年11月 （6）
- 2006年10月 （11）
- 2006年9月 （4）
- 2006年8月 （5）
- 2006年7月 （2）
- 2006年6月 （3）
- 2006年5月 （7）
- 2006年4月 （2）
- 2006年3月 （1）
- 2006年2月 （14）
評論政策
評論說，我們鼓勵對話做出貢獻的博客。 請注意，雅虎可以在我們的判斷，刪除註釋如果他們偏離主題，不恰當，或以其他方式違反我們的服務條款 。
成為雅虎
你是一個天才的工程師，產品經理或設計師希望自己沉浸在一個充滿創意和樂趣的環境呢？ 然後來找到一個與我們的工作 。
元：
測試評論系統，這是下一段時間存在。 一切似乎都恢復正常了，所以給它去！
評論由管理員- 2008年4月21日＃
我認為這是常識檢查
typeof pity === 'undefined'，而不是使用構造像var pity = this.pity || {};尤其是假設代碼問題是一個合理的副產品自適應程序。如果您認為 Web開發人員計劃在無知觀眾說的語言和這個博客的讀者（或讀者的任何JavaScript博客作者誰採用此方法）是相互排斥的，那麼我們可能的趨勢，同意你的第三種形式是適當的。
但是，看到大多數開發商的“學習”複製和粘貼，它似乎是第二種形式可能會更安全，如果沒有其他原因，而不是防止這些惡劣的全局大家都深惡痛絕。
評論由扎克萊澤曼 - 2008年4月21日＃
在“VAR可惜= this.pity | | {}”和它的變種已成為近期頗為流行的JavaScript庫，和我喜歡我自己。 你必須給到假設你使用它的地方布爾值不是你的期望。
其中最有用的情況我會作為默認值的功能參數。 考慮：
函數 doSomething（一）{
A = A | |“默認值”;
}
如果變量“一”是不確定的在這裡，它會得到一個默認值，使之變“的”有用的，其餘的功能。
但如果你願意，我想這可以寫成：
函數 doSomething（一）{
A =（A！==未定義？答：“默認值”）;
}
評論由Frode丹尼爾森 - 2008年5月1日＃
[...]在撒謊，如果我說我是不是就這一個外部的影響。 道格拉斯克羅克福德有很多偉大的建議，這是一個我傾向於同意[...]
Pingback由scriptNode /我的新的編碼習慣 - 2008年8月2日＃
我喜歡怎樣的ExtJS的庫處理這一點。 這些抽象的開發人員遠離問題提供了一個實用程序來創建“命名空間。” 我不知道它們究竟是如何在幕後做它，但我知道，Douglas Crockford的JavaScript的網站是一個沉重影響其發展，所以我也不會感到驚訝地發現，他們使用一種以上的形式呈現。 作為一名開發人員，不過，所有我需要做的是這樣的：
Ext.namespace（'可惜'）;
或本較短的形式：
Ext.ns（'可惜'）;
我什至可以聲明多個層次上的一行：
Ext.ns（'可惜'，'pity.util'，'pity.util.text'）;
評論由伯尼馬戈利斯-十一月19，2008 ＃
另一種形式，我通常喜歡是：
this.pity | |（this.pity = {}）;
其原因是它避免了額外的“同值”的分配如果，全球已經存在的，我做同樣的函數傳遞的參數為：
函數 doSomething（一）{
A | |（A =“默認值”）;
}
良好的聲音傳播任何正確的... ...
評論由迭戈首位 - 2010年1月29日＃
但是，事情終於說服了我的第一種形式是最糟糕的是，IE得到錯誤的第二種形式，使負責任自適應方案失敗
我一直沒能找到任何信息，如何獲取 IE的第二種形式是錯誤的。
就個人而言，我一直在使用：
var fooObj;
if (fooObj === undefined) {
fooObj = {};
}
評論由周杰倫在俄勒岡州-七月12，2010 ＃
不要使用描述的方法在上面的文章，如果你知道什麼是對你有好處。 您的代碼將打破ES - 5嚴格模式。
評論由扎克萊澤曼 - 2011年3月29日＃
我建議只用函數形式的嚴格模式的聲明。 扎克的意見僅適用於文件的形式。
評論由道格拉斯克羅克福德 - 2011年3月29日＃