That's a great question, because this is one of those VBA features that exists but almost nobody talks about.

What Copilot told you is technically correct. A Static Sub just means that every local variable inside that procedure behaves as if it were declared Static, so it retains its value between calls instead of resetting each time the procedure runs.

However, just because you can use it doesn't mean you should. In practice, most developers avoid Static Subs and instead use Static only on the specific variables that actually need to persist. The reason is clarity and control. If you mark individual variables as Static, it's obvious what's being remembered between calls and what isn't. With a Static Sub, everything is persistent whether you intended it or not, which can lead to confusing bugs later when values don't reset like you expect. Which is why you should always initialize variables inside your subs - except of course ones you want to remain Static.

There's also the issue of hidden state. When a procedure quietly remembers values from previous runs, it can make debugging a lot harder, especially if someone else is reading your code or if you come back to it months later wondering why something isn't behaving correctly.

Static variables themselves are useful in certain cases, like counters, simple caching, or remembering the last value processed. But making an entire procedure static is usually overkill and removes a lot of control.

So the short answer is: you're better off sticking with regular Subs and only using Static on the specific variables that need it. It keeps your code more predictable, easier to read, and much easier to maintain. And honestly, I much prefer TempVars for things like this. Lots of benefits to them (video explains).

Plus TempVars make Adam happy.

Thanks for clearing it up. I will definitely avoid using these and I agree with Adam, TempVars are awesome!