Re: Static Variables in a subprocedure

Hi Barbara -

On Thu, 07 Feb 2008 17:18:31 -0500, Barbara Morris
<bmorris@xxxxxxxxxx> wrote:

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.

All global variables subject to being "messed with". Even static
local variables are subject to being "messed with" inside of the
procedure.

Competent programmers pay attention to what they are doing, so I don't
consider protection from being messed with as a reason for lying to
the compiler to allow a single procedure to have two different
prototypes.

After all, isn't lying to the compiler a way that a program can "mess
with" a procedure? A procedure prototype with EXTPROC can be created
with different parameter types and lengths, with the potential for
decimal data errors, corrupted storage, etc. Shame, shame, shame! <G>

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.