全球支配，第二部分
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年6月 （4）
- 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 = {};
}
评论由周杰伦在俄勒冈州-二零一零年七月十二日＃
不要使用上述文章中所描述的方法，如果你知道什么对你有好处。 您的代码将打破ES - 5严格模式。
http://perfectionkills.com/unnecessarily-comprehensive-look-into-a-rather-insignificant-issue-of-global-objects-creation/
评论由扎克莱泽曼 - 2011年3月29日＃
我建议只使用严格模式声明函数的形式。 扎克的意见仅适用于文件的形式。
评论由道格拉斯克罗克福德 - 2011年3月29日＃