Discussion on:

Preserve procedure variables with Static in VB6

The takeaway of the article says:
"Peter Aitken demonstrates the benefits of using Static"
but the article is simply a description of how to declare Statics without mentioning any real uses. Thus the description of benefits should read:
"Declare a variable as persistent (static) to make sure that the value persists between calls"

Real world benefits include:
- the ability to store a persistent value in a local variable instead of a global variable. This avoids having to worry about the possibility of another function disrupting the value between calls, and reduces the number of variable names that you have to think about.
- caching values to speed up subsequent access to the function. An example would be a function that looks up a users security or personal information in a database; the first call would look up and cache the values and subsequent calls would use the cached values instead of repeating the database access.
- preventing recursion in event procedures in VBA. Create a boolean static called blAlreadyRunning and check to see if it is true before continuing with the code in the procedure. If it is true esit sub, otherwise set it to true and continue...
- preventing runaway recursion in recursive procedures by incrementing and checking a static counter.

Perhaps more of these articles could have a second page that describes some use cases.

If it's straight procedural code static variables can be a useful way of implementing protected properties or class function type constructs. In OO code they mean your design is poor in my opinion.
Runnaway recursion is definitely a fault in the algortithm for instance. It might be necessary to use as a stop gap defensive measure, but the requirement always indicates your exit condition is incorrectly specified.
The cache example is fine in terms of solving a performance, but only at the expense of a feature problem. How do you signal the cache is out of date. Yes I know how, but techniques like this and any other for that matters are not a free lunch. At all costs always look to avoid the let's use this feature because it's there syndrome.

Tend to steer clear of this sort of thing myself having once run in to someone who thought global static procedure variables were a clever idea. F'ing nightmare than was.

I've always preferred to use Private variables at the module level rather than Static variables at the procedure level, personally.

I'll grant the benefit of not having to have quite as many distinct names if you're going to use Statics instead of Class/Module Privates (that almost sounds dirty, doesn't it?), but I find that you're generally better off with Module Privates because they're in their own distinct section and obvious to the casual reader...you don't have to hunt down the variables that're preserved between calls.

The remainder of the benefits can all be accomplished whether you're using Static, Private, or Public variables (but see my first point), so I don't necessarily consider them to be benefits specifically related to Static variables.

A question, rather than a comment, if I may "if static variables are used can one reuse the variable name in other subroutines and functions ?"