Re: Static Variables in a subprocedure

[Barbara Morris <bmorris@xxxxxxxxxx>]

Ken Sims wrote:
> ...
> Personally I define all such "resetable" variables as global
> variables.  Most of my service programs have an "open" procedure
> (which calls the "reset" procedure), a "reset" procedure, and a
> "close" procedure.

If the module is acting as an "abstract data type", where all the 
procedures work with the same static data, it makes perfect sense to use 
global variables for the data.  What you describe sounds like this type 
of module.

In the case where a single procedure has some static data that should be 
private to the procedure, using a global variable opens up the 
possibility that all the procedures in the module can mess with the 
data.  Physically limiting access to just that one procedure tends to 
simplify maintenance.  Even though you have to jump through a hoop to be 
able to reset the private static data, it's a small and finite hoop. 
Figuring out what will be impacted if you change the nature of your 
should-be-private-but-is-public static variable can be a large and 
infinite hoop.