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

Question

After finding a "procedure to large" error on a specific subroutine of a module, I am refactoring the code in the module. I was curious on how effective the refactoring is at reducing the compiled code size.

So I was wondering if there is a way to see the size of the compiled code of a subroutine in a Module of Excel 2016?

My attempts so far have been limited to searching online for methods to determine the size of a compiled module or subroutine in VBA.

It led me to the limits of VBA as listed in here . It does not mention a way to see the size of the procedure compiled, nor does it mention whether that is (practically) possible.

(As was mentioned in the comments, the current maximum size of the compiled procedure is 64K as stated here .)

1. I think the compiled procedure size is not 1 on 1 related to the number of lines. (Because that does not take into account short or long lines. But I am currently unsure about how the vba-procure is compiled, and consequently how lines contribute to the compiled file size, otherwise a solution could possibly be to compute the compiled file size.)
2. Nor is the procedure 1 on 1 dependent on the size of the code as stored as a '.txt' file. (because it can contain comments which do not contribute to the compiled code size)

Disclamer - I am well aware of the shortcomings of the old code I am modifying. That it is poorly written, I think this quote of Bill Gates illustrates it quite well:

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

I think refactoring, and breaking the code up in shorter subroutines is an appropriate first step. To monitor this process, in combination with the hard bottleneck presented by VBA as the Procedure too long - error led me to this question.

Answer 1

No, you can't do that. VBA is compiled in several stages, it's part p-code, part interpreted, and at the end of the day the size in kb of the compiled procedure isn't what you need to work on.

---

You need to read about Abstraction , urgently. A procedure that triggers this compiler error is over 10K lines of code. A healthy procedure at the appropriate abstraction level might be somewhere between 500 and a thousand times smaller than that (not kidding) - the size of the compiled code is absolutely meaningless .

If you're worrying about the size of the compiled code, you're not writing the code for a human.

Code isn't written for a compiler to crunch and a runtime environment to run. Code is written for a human maintainer to read, understand, follow, debug, modify, extend, etc. Without any level of abstraction, code is a boring, excruciatingly mind-numbing series of executable statements that are invariably redundant, inefficient, and annoyingly bug-prone.

There are 3rd-party tools you can use to analyze VBA code. MZ-Tools 3.0 was free, but the latest version isn't. It has a feature that can tell you how many lines of code are in each procedure of each module, how much of it is commented-out, whether you have unused variables, etc.

Rubberduck is free and open-source, under active development (disclaimer: I own the project's repository), and has a code metrics feature (distinct from code inspections ) that can probably help you identify the most problematic areas (although, parsing a 10K-liner module might take a while):

Lines is your "lines of code" metric; Cyclomatic Complexity is a rough indicator of the different possible execution paths in your code (how much sense that metric makes at a module-level aggregate is debatable); Maximum Nesting is also an indicator of how badly "arrow-shaped" code might be.

High values in these metrics are a sign that you may need to extract methods .