【问题标题】:Javascript, using one single local object instead of many local variablesJavascript,使用一个本地对象而不是许多本地变量
【发布时间】:2015-08-28 15:59:59
【问题描述】:

我经常使用 jslint 和工具来验证我的代码是否存在编程错误等...

在我的编程过程中,我经常发现我需要一个局部变量或一个局部函数来做一些简单的事情。所以我去我本地范围顶部的主要单 var 语句并调整它,有时会破坏我的创意流程。所以有时我会在我的代码中间声明一个单行 var 以继续我的编程,然后在重构期间将其移动到顶部的 var 语句中。

我今天有一个想法,我想探索,但在 Google 或 stackoverflow 上没有找到任何内容。

我的想法是这样,只需声明一个临时对象并将其用于任何需要。例如:为新变量或函数添加一些属性。

所以不是:

// if I omit the last comma, the next variable will be a global
var variable1 = "Hello World!",  
variable2 = "Testing...";  

(... some code ...)
var variable3 = 42;

我会改用:

var temp = {};
temp.variable1 = "Hello World!";
temp.variable2 = "Testing...";

(... some code ...)
temp.variable3 = 42;

所以我不会冒污染全局命名空间的风险,我会根据需要声明变量,并且不会为 var 语句而纠结,因为我总是知道变量以“temp”开头。在本地范围内。

任何意见或建议将不胜感激。

【问题讨论】:

  • 我不认为有真正的区别,一旦你牢记你的范围。一旦你管理你的范围引用,你不应该污染你的全局命名空间。JS是通过值而不是引用传递的,所以我看不出有什么不同! :(
  • 你会更好using closures to maintain scope,让你的代码更具可读性,防止全局范围的污染等等。
  • 我的另一个想法是代替命名我的临时对象 temp 我可以将其命名以给出范围的概念并且仍然知道它是链上的本地对象。例如:temp_inner、temp_inner_inner。
  • 跳出的一个问题是这段代码是否经过了缩小过程。由于这些变量是对象的属性,它们不会被缩小。不一定是大问题,但如果您的模块/库很大,它可能会增加一些重量。

标签: javascript variables object global-variables local-variables


【解决方案1】:

问自己一个问题:你见过其他人这样做吗?我个人没有。这应该给你一个迹象,表明有充分的理由不这样做。 本质上,您建议的是“命名空间”,这并不新鲜。在很多情况下都可以,但在这里——对于临时变量——我建议它突出代码气味。

您提到了全局命名空间的污染,但这应该很少成为问题。通过将代码分解为函数、类或模块,您的变量将包含在该范围内。

所以有时我会在我的中间声明一个单行 var 代码继续我的编程,然后将其移动到顶部 var 事后重构时的声明。

这听起来很糟糕。听起来您的代码块很长,这表明您应该从代码中提取函数。

我还要指出,在您的示例中,您还使用名为 temp 的变量污染了全局命名空间。

想想常见的 JavaScript 代码库; jQuery 只暴露了 jQuery 或 $ 变量。 Lodash/Underscore 只有 _。 Backbone 有“Backbone”等。为什么您的应用程序特别?只要有一个曝光点。

您的问题的另一个潜在解决方案是使用模块系统。编译后,代码将被包裹在一个闭包中,根本不会暴露给外界。使其模块化也将导致应用程序更整洁。

【讨论】:

  • 我同意除了第一条评论之外的一切! ^ 仅仅因为其他人不这样做并不意味着它可能不是一个好主意! ^
  • 没有人这样做并不意味着这是一个坏主意……我认为值得探索。
  • 你提到了全局命名空间的污染,但这应该很少成为问题Really?
  • @Liam 我认为他的意思是你不应该发展成一种方法来解决这个问题。
  • 嗯,这基本上是命名空间,这本身还不错;然而,代码问题的描述和它在这里的使用方式表明这将是对命名空间的滥用。这并不是一个真正的新想法,您只是以我认为不明智的方式使用它。我改写了我的答案,以更多地关注命名空间。
【解决方案2】:

避免全局范围污染的最佳方法是将代码分解为小的独立函数和模块。

您提到必须重构代码,因为您的代码中间有变量声明。我个人认为你不需要这样做,我实际上发现代码更容易推断何时声明变量尽可能靠近它们的使用位置。只要您对范围和提升的工作方式感到满意,我看不出您应该将所有声明放在函数顶部的理由。

【讨论】:

  • 嗯 jshint 之类的东西对于我们应该在哪里放置 var 语句有点宽容,但 Crockford 建议单个 var 应该是最好的方法。对于将我的代码分解成更小的部分,完全同意这一点,但有很多很好的理由说明为什么有时情况并非如此:代码维护、交付的冲动等等......
  • 我个人不喜欢单一的 var 模式,因为我觉得它让我的代码更难重构。使用多个 var,我可以简单地剪切和过去我的声明,而使用单个 var,我总是必须确保逗号是正确的。当然它可能看起来更干净,但我觉得它不会带来任何其他好处。
  • “Crockford 建议单个 var 应该是最好的方法”——他到底是在哪里说的?你的意思是一个 var 关键字?如果是这样,那与您的建议完全不同。此外,“代码维护”是不破坏代码的可怕、可怕的理由。请记住,您在这里问的是关于最佳实践的问题。
  • @ColinRamsay 哈哈!代码维护的权利 :-) 好的创意流程 :-)
  • 请注意:Crockford 对 single var statement 的建议最初是在 JS 仅在浏览器中时编写的,并且仍然存在对大幅优化交付大小的担忧。再一次,这只是一个建议,并且有很多现代风格指南不推荐单个 var 语句。一个更相关的原因是强调variable hoisting,以便新开发人员清楚地了解引擎在幕后所做的事情。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-11-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多