On Tue, Jul 8, 2014 at 9:22 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 7/8/2014 4:46 AM, D*B wrote:
Additinal note:
global data and coupling procedures by global data is not bad design!
Bad design is to define data global, which is needed only local!!!
This surprises me, which means I probably do not understand what you
mean. Could you please give an example of good design that couples
subprocedures with global variables?
I'll join the party and say that it isn't *necessarily* bad design to
have a module which contains a bunch of highly related and tightly
coupled subprocedures. It might make sense to have some module-level
data shared among all those subprocedures, and as Vern says, passing
that data around with parameters is cumbersome. Repeating those
parameters in every subprocedure would clutter the prototypes and be
redundant.
Remember, "global" is tantamount to "local to the module". In
languages with more layers of scoping, you may find that a for loop
has its own local variables, and those variables are not visible to a
sister for loop in the same function. That function, in turn, has
local variables that are not visible to sister functions in the same
module (or to an enclosing function; plenty of languages have
arbitrary levels of function nesting). Each module has variables that
are not visible to other modules in the same program, but we just so
happen to call those module-level variables "global", simply because
"source member" happens to coincide with "module".
So what Dieter and others are effectively saying is: The proper
design makes each variable as local as appropriate. In general,
smaller scope is preferable to larger scope (because it reduces the
chance of unintended side-effects), but that doesn't mean larger scope
is automatically bad.
John Y.
midrange.com
