如何在VBA Excel 2016中查看已编译子例程的大小？

在模块的特定子例程上发现“procedure to large”错误后，我正在重构模块中的代码。我很好奇重构在减少编译代码大小方面有多有效

所以我想知道是否有办法查看Excel 2016模块中子程序编译代码的大小

到目前为止，我的尝试仅限于在线搜索确定VBA中已编译模块或子例程大小的方法

这使我了解了VBA的极限，如中所列。它没有提到查看编译过程大小的方法，也没有提到这是否（实际上）可能

（如注释中所述，编译过程的当前最大大小为64K。）

我认为编译过程的大小与行数无关。（因为这不考虑短行或长行。但我目前不确定vba是如何编译的，因此也不确定行如何影响编译后的文件大小，否则解决方案可能是计算编译后的文件大小。）

过程1对1也不依赖于存储为“.txt”文件的代码大小。（因为它可以包含不影响编译代码大小的注释）

Disclamer-我很清楚我正在修改的旧代码的缺点。这篇文章写得很糟糕，我认为比尔·盖茨的这句话很好地说明了这一点：

通过代码行测量编程进度就像测量 按重量计算的飞机制造进度

---

我认为重构和将代码分解成较短的子例程是合适的第一步。为了监控这个过程，再加上VBA由于

过程太长而出现的硬瓶颈，错误导致我提出了这个问题。
不，你不能这样做。VBA的编译分为几个阶段，一部分是p代码，一部分是解释代码，最终编译过程的大小（kb）不是您需要处理的


您需要立即阅读有关抽象的内容。触发此编译器错误的过程超过10K行代码。在适当的抽象级别上，一个健康的过程可能比这个过程小500到1000倍（不是开玩笑）编译代码的大小绝对没有意义

如果您担心编译代码的大小，那么您不是在为人编写代码

代码不是为编译器运行和运行时环境运行而编写的。代码是为人类维护人员编写的，用于阅读、理解、跟踪、调试、修改、扩展等。没有任何抽象级别，代码是一系列令人厌烦、极度麻木的可执行语句，这些语句总是冗余、低效且容易出现令人烦恼的错误

有一些第三方工具可用于分析VBA代码。MZTools3.0是免费的，但最新版本不是。它有一个特性，可以告诉您每个模块的每个过程中有多少行代码，有多少被注释掉，是否有未使用的变量，等等

是免费的、开源的、处于积极开发中的（免责声明：我拥有项目的存储库），并且具有代码度量功能（不同于代码检查），可能有助于您确定最有问题的领域（尽管解析10K线性模块可能需要一段时间）：


行是您的“代码行”度量；圈复杂度是代码中不同可能执行路径的粗略指标（度量在模块级聚合中的意义有多大尚待讨论）；最大嵌套也是“箭头形”代码可能有多糟糕的指标

这些指标中的高值表明您可能需要提取方法。
亲爱的@vityta，感谢您对已编译子例程文件大小的估计方法提出建议。从我迄今为止看到的信息和论坛帖子来看，行数似乎确实提供了一个很好的指标来估计编译的子程序文件的大小。我认为我的子程序中的行数是离题的。
圈复杂度
将是约会网站上包含的一个很好的指标。棒极了。接下来，在编写和重构代码时，我必须仔细研究
圈复杂度
和
最大嵌套
。话虽如此，我还是会成为一个“代码行纳粹”，因为当我减少代码行时，会有“个人成就感”。@Mathieu Guindon，谢谢你详尽的回答。从您的回答和我目前的理解来看，编译代码的大小是没有意义的，因为抽象级别的差异使得重构子程序代码的效果实际上是不可跟踪的。谢谢你给我指点工具，让我能更有效地解决XY问题！我是Rubberduck的忠实粉丝，我会更加坚持不懈地应用它。@a.t.您可能需要密切关注Extract方法重构工具的重写进度；-）我喜欢这种情绪，但这并不能回答这个问题。