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

Question

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

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

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

它让我发现了 VBA 的局限性，如 here 中列出的那样。 。它没有提到查看编译过程的大小的方法，也没有提到这是否(实际上)可能。

(正如评论中提到的，编译过程的当前最大大小为 64K，如 here 所述。)

1. 我认为编译后的程序大小与行数并不是1对1的关系。 (因为这没有考虑短行或长行。但我目前不确定 vba-procure 是如何编译的，以及行如何影响编译文件大小，否则解决方案可能是计算编译文件大小.)
2. 一对一的过程也不依赖于存储为“.txt”文件的代码的大小。 (因为它可以包含不会影响编译代码大小的注释)

免责声明 - 我很清楚我正在修改的旧代码的缺点。它写得不好，我认为比尔·盖茨的这句话很好地说明了这一点:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

我认为重构并将代码分解为较短的子例程是适当的第一步。为了监视这个过程，结合 VBA 提出的硬瓶颈，如 Procedure too long - 错误让我想到了这个问题。

Answer 1

不，你不能那样做。 VBA 分几个阶段进行编译，它的一部分是 p 代码，一部分是解释的，最终，编译过程的大小(以 kb 为单位)并不是您需要处理的。

<小时/>

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

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

代码不是为编译器处理和运行时环境而编写的。代码是为人类维护人员阅读、理解、遵循、调试、修改、扩展等而编写的。如果没有任何抽象级别，代码就是一系列无聊、令人难以忍受的可执行语句，这些语句总是冗余、低效且烦人的容易出现错误。

您可以使用第 3 方工具来分析 VBA 代码。 MZ-Tools 3.0 是免费的，但最新版本不是免费的。它有一个功能，可以告诉你每个模块的每个过程中有多少行代码，有多少代码被注释掉，是否有未使用的变量等等。

Rubberduck是免费和开源的，正在积极开发中(免责声明:我拥有该项目的存储库)，并且具有代码指标功能(与代码检查不同)，可能会有所帮助您确定了最有问题的区域(尽管解析 10K 线性模块可能需要一段时间):

行数是您的“代码行数”指标；循环复杂度是代码中不同可能执行路径的粗略指标(该指标在模块级聚合中的意义有多大是值得商榷的)； 最大嵌套也是“箭头形”代码可能有多严重的一个指标。

这些指标的值较高表明您可能需要提取方法。