Avoiding Global Variables - revUp 93
jimaultwins at yahoo.com
Sun Jun 6 13:17:18 CDT 2010
My experience with people who are new to a language or new to
programming tend to simplify or "round off" their efforts and produce
Use globals as a short cut to passing parameters because it is simpler
Develop programming patterns that mean they use the same global names
Forget that globals are owned by Rev, not the stack(s)
Lose track of how many script containers touch and change the same
Try to reuse globals, thinking that they will just keep track of
clearing the global variable when they need to.
I used to be leader of the Advance Hypercard Special Interest Group
back in the day. The global naming was particularly problematic when
a school teacher decided to jump in and do their own grade book and
-- as one declaration, without the 'g' prefix
-- then in field scripts, etc used
put "Tom Jones" into mySelectedStudent
-- forgetting to declare the global at the top of the script container
-- or forgetting they had declared it and it already had a value
-- or forgetting that the global value was supposed to be
line 5 of field "studentList"
-- and defined it as the string "Tommy Smith"
-- thus dueling data formats
This became worse when they tried to employ "stacks in use", which
meant that many globals became hidden library instances. Now the
globals were not even in the same stack or logical project. They had
a fighting chance if they were the authors of the 'stacks in use', but
not when they acquired the stacks of others.
Our Hypercard group actually designed some scripts to map the globals
and look for duplicate locals or missing global declarations. Script
locals were not a feature of Hypercard. If the 'g' prefix were not
used, mapping was essential for finding 'cross-wiring' (as we called
Hypercard was designed to run across hard drives and computers, so now
globals became more difficult. You had a choice to navigate and use
the remote environment or keep using your own. Remember the days of
"Go Recent", "Pop Card" ? On an AppleTalk network, like a classroom,
this could lead to significant degrees of anarchy. The students would
use the same global names as the instructor, but for different tasks.
I found that most new programmers, including me, had challenges with
the scope of variables. Certainly experienced programmers have
mastered the use of global variables and developed work patterns to
use them wisely, thus they have become a valuable tool. To the new
programmer, they create extra bugs that are more difficult to find and
There was one programming student who could not understand that
globals were persistent, even if he closed his stack. He would leave
Hypercard running all the time, no matter which stacks he was
developing or exploring. Opening someone else's stack created
variables you did not know about.
You can imagine at the end of 4 weeks how many globals were safely
nestled into his application memory. It was a clan of somewhat-
related variables, most were of his own creation. After all, part of
the thrill of Hypercard was seeing all the wonderful stacks built by
Our Hypercard group rule was if your stacks were for distribution,
sharing, and fun, don't use globals (or use unique names).
Hope this adds to the discussion by looking back to the beginning of
the Hypercard-space-time continuum and the universal nature of globals
and their nebulae.
More information about the use-livecode