ColdFusion非范围与VARIABLES范围:性能与可读性？

Question

在我的ColdFusion代码中,我习惯于始终将变量范围视为我的默认范围(即,当另一个范围不适合时).我的理解是,这提高了效率,因为ColdFusion处理器不必花费周期来确定包含变量的范围.但是,我总是对这使我的代码变得多么冗长感到恼火.

实际上,我的问题是,明确确定每个值得冗长的变量？我知道每个应用程序都有不同的"价值"定义,但我想从更有经验的开发人员那里得到一些意见.你总是把每个变量作为范围吗？仅限生产代码？您是否发现具有明确范围变量的代码更具可读性,并且增加的可读性是否更加"更漂亮"(缺少更好的单词)代码？提前感谢您的回复.

Answer 1

答案的客观部分(因此人们不投票将其视为"过于主观")是因为总是存在范围变量的假设性能增益.也就是说,我听到一些 - 轶事 - 暗示在ColdFusion(而不是Railo)上,没有确定变量范围变量的范围实际上更快.

但在现实世界中:差异无关紧要.

我错误地保持代码更清晰,更容易阅读,为此我只说必要时范围变量 - 范围变量.

注意:即使CF在没有范围的情况下"找到"它们,我也始终使用表单,URL等变量.将这些问题作为范围似乎很麻烦(再次,主观,在这种情况下只有IMO).

Answer 2

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

1. 可读性
2. 出血和性能

由于这两个原因，我会（通常）建议您在 CFC 类内外确定所有作用域。如果你这样做，你永远不会对结果感到惊讶。但是，这是两种不同的情况：

在 CFC 内部：

始终作用域，Variables因为它是在类的方法和主体之间共享的“受保护”作用域。并且仅在您非常确定要使用它时才使用它。您可以像实例化类的属性成员一样使用它，但如果在单例类（缓存到Application作用域）中使用它，请务必小心。这可能会导致意外出血。此外，如果有任何同名的外部变量，您可能会再次无意中将它们从空中抓取。不是你想要的。此外，Variables在 CFC 中不限定范围会令人困惑，因为还有var不带范围前缀的局部范围值。Variables如果您在此处使用它，请仅在此处确定范围。

在 CFC 之外：

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

搜索顺序：

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