ColdFusion 非作用域与变量作用域：性能与可读性？

在我的 ColdFusion 代码中，我养成了始终将变量作用域视为默认作用域的习惯（即，当另一个作用域不适合时）。我的理解是，这提高了效率，因为 ColdFusion 处理器不必花费周期来确定变量所包含的范围。然而，我一直对这让我的代码如此冗长感到恼火。

所以，我的问题是，实际上，明确地确定每个变量的范围值得冗长吗？我知道每个应用程序对“价值”都有不同的定义，但我只想从更有经验的开发人员那里获得一些意见。你总是对每个变量进行范围限制吗？仅适用于生产代码？您是否发现具有显式范围变量的代码更具可读性，并且增加的可读性是否胜过“更漂亮”（因为缺乏更好的词）代码？预先感谢您的任何回复。

在确定范围时，需要考虑两件事：

1. 可读性
2. 出血与表现

出于这两个原因，我（通常）建议您在 CFC 类内外设置所有范围。如果你这样做，你永远不会对结果感到惊讶。然而，这是两种不同的情况：

CFC 内部：

始终范围Variables因为它是类的方法和主体之间共享的“受保护”范围。并且仅当您非常确定要使用它时才使用它。您可以像实例化类的属性成员一样使用它，但如果在单例类中使用它（缓存到Application范围）。这可能会导致意外出血。此外，如果存在任何同名的外部变量，您可能会无意中抓住它们。不是你想要的。此外，没有确定范围VariablesCFC 中的范围令人困惑，因为也有本地var不带范围前缀的范围值。只是范围Variables如果你在这里使用它。

在 CFC 之外：

您可以承担不范围Variables在 CFM 页面/包含中，只要它是明确的，恕我直言。实际上应该不会有性能损失，因为 CF 将首先检查此范围（在 CFC 之外）。我的一般偏好是在设置/声明它时首先确定范围，然后，如果它清晰并且在视觉上下文中，则将其保留为无范围。如果页面很长，或者我已将页面（例如长报告）分成块（包含），我将确保再次为其添加前缀，以便非常清楚它来自哪里。如果我始终如一地确定所有其他范围（我推荐的范围）should明确无范围是Variables，但我喜欢说清楚。特别是如果其他人也在代码库上工作的话。因此，如果不清楚，请对其范围进行界定。良好的经验法则。

搜索顺序：

最后，我讨厌人们谈论搜索顺序，然后将 CFC 和页面范围混在一起。请记住它们是不同的，CF 没有很好或清楚地记录这些（Local and Var处于“平等”状态，最后获胜者获胜，Arguments之前会发现Local在 CFC 中未声明或过载时，Variables and Property也混合在一起）。在一个page（CFM 模板/包括）Variables范围是默认值并且首先搜索。一个例外是查询块上下文中的查询范围。同样，没有很好的文档记录，并且在 CF 中我们并不总是像某些语言那样考虑块作用域，但这实际上就是这种情况。在查询上下文之外，期望Variables特朗普。如果您不确定某个案例，请对其进行范围分析或测试。另请记住，this, Request, Application, and Session当 CF 遇到无前缀变量时，不会搜索作用域。