为什么var x=x=x_x=x_x\ {}比var _x=x_x\ {}更彻底？

Question

作为初学者，在编写干净的Javascript代码的过程中，我最近读到了关于这篇文章关于JavaScript中的名称空间的文章，这时我偶然发现了这一段：

下一个示例顶部的代码演示了在定义变量(对象命名空间)之前可以检查变量(对象命名空间)是否已经存在的不同方法。您通常会看到开发人员使用选项1，但是选项3和5可能被认为更彻底，选项4被认为是最好的实践。 //这不检查//全局命名空间中是否存在“myApplication”。操作不当，因为您可以轻松地// clobber使用同名为var myApplication ={}的现有变量/命名空间；/*下面的选项*做*检查变量/命名空间是否存在。如果已经定义了该实例，则使用该实例，否则将为myApplication分配一个新的对象文本。备选案文1: var myApplication = myApplication连体{}；选项2: if(! myApplication ) MyApplication = {}；备选案文3: var myApplication = myApplication = myApplication连体{}选项4: myApplication维希(myApplication = {})；备选案文5: var myApplication =myApplication ===未定义？{}：myApplication；*/

选项1当然是我见过的大多数时候使用的选项，我对它有很好的理解。

选项2很好，但似乎事先缺少var myApplication或if(!window.myApplication)，否则如果myApplication不在全局范围内，if(!myApplication)会抛出错误，不是吗？

选项3是我遇到麻烦的地方:我的理解是首先执行myApplication = myApplication，在全局范围内执行myApplication (因为开始使用var )。我的问题是，我想不出有什么比选项1做更多事情的情况。

在我看来，选项4更好地编写了window.myApplication || (myApplication = {})，以避免如果myApplication不在全局范围内时抛出错误。

选项5排除了undefined以外的假y值，但这是个好主意吗？如果myApplication是一个空字符串，那么其余的代码可能会失败，不是吗？

是否有人能够阐明不同备选方案之间的差异，特别是解释为什么备选方案3被描述为更彻底？

Answer 1

如果文章声称选项3“更彻底”，这是不正确的。任务链的中间一点意义都没有。

是否有人能够阐明不同备选方案之间的差异，特别是解释为什么备选方案3被描述为更彻底？

首先，一个警告:在2018年，你可能不想使用这些。相反，使用适当的模块，或者通过与相关工具一起使用的各种模块定义语法(AMD、CommonJS、RequireJS)，或者使用带有import和export的ES2015+模块(可能是一个相关的工具，比如巴贝尔，也许是Webpack或褐化，尽管当前版本的Chrome、Safari和Edge支持模块，而且火狐目前也支持一个标志)。

为什么var x = x = x || {}比var x = x || {}更彻底？

事实并非如此。

选项2很好，但似乎事先缺少var myApplication或if(!window.myApplication)，否则如果myApplication不在全局范围内，if(!myApplication)会抛出错误，不是吗？

是。(假设生产发生在全球范围内。如果它不在全局范围内，并且在当前作用域链中的任何位置都有一个作用域内myApplication，那么它不会抛出，因为myApplication不会是一个未解决的符号。)

选项3是我遇到麻烦的地方:我的理解是首先执行myApplication = myApplication，在全局范围内执行myApplication (因为开始使用var )。我的问题是，我想不出有什么比选项1做更多事情的情况。

不，如果你有

var myApplication = myApplication = myApplication || {}

这是事情发生的顺序：

1. var myApplication在不存在的情况下创建全局，如果不存在，则保持不变
2. 对myApplication || {}进行计算，并在myApplication (如果是真的话)或{} (如果不是的话)中接受值；让我们调用value1
3. 执行myApplication = value1 (中间的一个)，结果是value1
4. 再次执行myApplication = value1 (左边的那个)，没有什么好的理由。

在我看来，选项4更好地编写了window.myApplication || (myApplication = {})，以避免如果myApplication不在全局范围内时抛出错误。

确实如此。

选项5排除了undefined以外的假y值，但这是个好主意吗？如果myApplication是一个空字符串，那么其余的代码可能会失败，不是吗？

是。