令人信服的在全球使用Excel中的本地范围的论据
我相信在Excel中使用本地化范围名称可能更好。 在Excel 2003中，使用（我将调用的）A列左上angular的名称input框创build范围时，我知道它们是全局的。 我知道这是可能的，尽pipe在大多数情况下，不可能在名称相同的工作表上在本地添加一个Range，这在Excel和VBA中都会造成非常混乱的行为？
我search了一下，没有find关于这个主题的文章（在这之后我可能需要自己写博客）。 我想知道其他专业Excel开发人员在做什么以及为什么？
我认为全球与本地问题取决于您处理的用户types以及您构build的解决schemetypes。 Charles可能会与用户在范围和公式上投入巨资的解决scheme合作; 我深入VBA代码。 这里所要求的方法有着天壤之别。 我不会说查尔斯是错的 – 他可能是正确的解决scheme。 但他对我来说是错的
我使用了许多模块化的解决scheme，这些解决scheme在不同的工作表上以编程方式生成相同的范围。 我广泛使用名称，因为它有助于限制在代码中使用硬编码的范围引用，还提供了一种通用解决scheme，可以在不同模板之间运行。 我很less使用标准的范围下拉下一个公式栏创build范围 – 创build本地名称在mule子是一个正确的痛苦。
查尔斯关于全球/本地混淆的观点并不适用于我，因为它全是程序化的，这样的错误将会是一个错误，而不是用户的挫败感。 他们没有看到这些范围。
在用户与名称交互的情况下，我确实希望Excel以不同的方式签署全局名称以避免用户混淆。 根据我的经验，如果我已经定义了范围，用户不会遇到麻烦。 他们不必担心地方/全球问题，因为名字已经在那里了。
让我们不要涉及相对与绝对的范围名称的问题…这是用户混淆蠕虫的另一个可能！
关于使用本地名称的可取性，意见不同。
一方面，尽可能限制范围，所以使用本地。
另一方面，如果您有重复的本地名称（同名多个表单中存在），错误的可能性会迅速增加，如果您没有重复的本地名称，则使用它们没有多大意义。 此外，它很容易无意中创build一个与本地名称相同的全球名称：这导致混淆和容易出错（有些人会说错误）Excel / VBA的行为。
免费的名称pipe理插件（由Jan-Karel Pieterse和我自己撰写）使得本地名称更容易处理，例如在本地和全局之间轻松转换，改进了本地名称的可见性，过滤和标记重复的全局/本地名称。
从VBA的angular度来看，我很less使用它们，但是从公式的angular度来看，有时候本地名称是有用的。
您的工作簿是一个商业应用程序，表单是模块。 想想它像任何软件问题。
你想尽可能地限制你的名字的范围：
- 尽量减less意外和不可见的误用。
- 避免担心以前是否使用过某个名称。
- 为了尽量减lesssearch“什么是…改变了这个？”的程度。
- 因为它不花你任何东西，而全局variables不会带来任何好处。
对本地名字的交叉引用是额外的工作，并且不太可能是偶然的，所以我不得不同意Charles的观点，即重复的本地名字会增加错误的可能性。
有一个原因，当我们发明结构化编程时，我们也摆脱了“空白共同”。 理由同样适用于电子表格。
有一件事可以使你的电子表格模型变得更强大：当你想要声明一个全局的，或者你正在做一个交叉表参考时，考虑一下创build一个函数还是一个类是更好的。 情况并非总是如此，但我发现通过封装“有趣的”计算来减less复杂性已经足够了。
这是一个意见的问题：不同的用户会有不同的喜好。
我使用全局名称，因为我需要一个方便且稳定的标签来标识整个工作簿中的范围 – 在整个项目中的任何工作表和VBAstream程的公式中。
从本质上讲，我认为命名范围是一个全局variables，是稳定交叉过程的基本工具。
本地名称是用于在不同的表单上声明不同的范围，并且这是混淆和错误的处方。 这就是说，乔尔古德温提供了一个很好的理由使用本地名称的答案：模块化代码（如模板生成器），在不同的工作表上做同样的事情。 我已经构build了完全相同的模板生成器。
我更愿意使用本地名称，如果有更好的接口可用于查看它们并在VBA中使用它们–JKP的名称pipe理器在我工作的地方使用得非常多，但它并不能消除微软devise的混乱和错误实现。