why are global variables bad for you ?
Alain Berdoz
I got the impression from recent postings that global variables are to
be avoided.
Could somebody tell me what's wrong with using them and what are the
pitfalls
Thank you,
--
Alain Berdoz Ber...@code7136.nrl.navy.mil
Research Engineer 202-404-8046
SFA,Inc www.sfa.com
Suite 200
9315 Largo Drive west
Largo MD 20774
-----------------------------------------------------------------------------
us
user <lars gregerson> to a recent poster (that most likely started this
question) and will give it on to my students:
<original tone lars gregerson beg>
Re: Global variables in GUI (05dec00)
... SOMEBODY POSTED A QUESTION ABOUT GLOBALS ...
It seems as if we are covering a lot of work on global variables today.
The short answer is: Don't use global variables.
The longer answer is: Don't use global variables unless you absolutely
have to.
<original tone lars gregerson end>
now,
1) using <global>s is perfectly ok (that's why they here on first
place), just like <for>s and <while>s and other intelligible 2nd
generation computer language constructs (that ML is built on) ... this
issue is very comparable to the sort of frenzy with <vectorizing> good
and comprehensive code to the point of <what the hell is this one-line
code supposed to do ...> (mind you, i love vectorizing).
-> don't get intimidated!
2) using <global>s is a blasphemy from a programmer's point of
view 'cause it shows that she/he didn't think <ahead> but was rather
sloppy ... and just kept adding on those never-ending <important set
up> parameters that she/he needed to use by all the axes - or whatever -
of a one single project ...
3) using <global>s is a problem in terms of book-keeping if(f) you end
up having zillions of them hovering around in your workspace, and start
having problems 'cause one <my_par> from func1 is mixed up with
<my_par> from func2 ... and <whos global> shows you 20 pages worth of
variables ...
4) using <global>s won't work in certain ML contexts, such as <gui
callback>s (see the various ng posters)
5) using <global>s actually is time consuming in ML (i don't know the
reason for this):
we did a lot of comparing, in a nutshell, here's the <profile> ranking
using constructs <struct.par1 struct.par2 struct.parN [SP]> as function
parameters vs <global par1 par2 ... parN> [GL]>:
SP untouched, i.e., the <field>s in your function are used but not
changed:
0.1
GL touched:
0.3
SP touched, i.e., the <field>'s entry is used and changed:
1
GL untouched
1.5
hence, eventually collecting your <global>s into a <struct> (i.e.,
cleaning up your <toolbox>) and passing it on as a parameter of your
<function>s is the most economic way to program stuff in ML ... and it
shows your intelligence, to boot.
just a note,
us
ps: let's not get too neurotic 'bout this, let's just have fun with ML
Sent via Deja.com http://www.deja.com/
Before you buy.
us
of course, the ranking was
SP untouched
.1
GL untouched
.3
SP touched
1
GL touched
1.5
sorry for mild confusion,
us
Lars Gregersen
>i'll always fondly remember the outburst of the notorious and seasoned
>user <lars gregerson> to a recent poster (that most likely started this
>question) and will give it on to my students:
>
><original tone lars gregerson beg>
>Re: Global variables in GUI (05dec00)
>... SOMEBODY POSTED A QUESTION ABOUT GLOBALS ...
>It seems as if we are covering a lot of work on global variables today.
>The short answer is: Don't use global variables.
>The longer answer is: Don't use global variables unless you absolutely
>have to.
><original tone lars gregerson end>
I'll try to give a reply to this (and try not to be neurotic
about it ;-)
I could have reversed the opposite argument and instead have said:
Global variables are useful for one purpose only: You have the
situation of putting together code in different toolboxes, possibly
written by different people, possibly written using different
programming styles with poor documentation. You simply can't make a
script that will call one function after another because the toolbox'
functions interact. You only have a short time to come up with
something that works and you'll probably never have to do it again.
For this purpose it may be the best solution (all things considered)
to use global variables. Even then it doesn't hurt to plan ahead: Make
a global parameter variable as a struct; so you later may turn this
into a parameter you can pass in a normal way.
In Matlab 4 (before the new set of ODE tools came out) you would use
global variables to send parameters from your main programme to the
'fun' that was called from e.g. ode45. It wasn't pretty, but it
worked. Now you can send parameters to 'fun' directly so you don't
have to use global variables for this anymore since the programmers
improved the tools in this respect (of course we made that our own
version of ode45 that did the same).
>now,
>
>1) using <global>s is perfectly ok (that's why they here on first
>place), just like <for>s and <while>s and other intelligible 2nd
>generation computer language constructs (that ML is built on) ... this
>issue is very comparable to the sort of frenzy with <vectorizing> good
>and comprehensive code to the point of <what the hell is this one-line
>code supposed to do ...> (mind you, i love vectorizing).
>-> don't get intimidated!
Hey, I also throw in a global variable here and there usually because
it gets the job done faster - never because it provides you with a
better solution. And yes, global variables in Matlab are not as bad a
COMMON BLOCKS in FORTRAN!
>2) using <global>s is a blasphemy from a programmer's point of
>view 'cause it shows that she/he didn't think <ahead> but was rather
>sloppy ... and just kept adding on those never-ending <important set
>up> parameters that she/he needed to use by all the axes - or whatever -
> of a one single project ...
If you plan for using code for any length of time you have to plan for
useful data structures. Sometimes it actually helps the coding if you
plan a useful set of data structures before you start coding. It will
help you setting up the data flow!
>3) using <global>s is a problem in terms of book-keeping if(f) you end
>up having zillions of them hovering around in your workspace, and start
>having problems 'cause one <my_par> from func1 is mixed up with
><my_par> from func2 ... and <whos global> shows you 20 pages worth of
>variables ...
The nice thing about Matlab functions is that they do normally not
have sideeffects everything that goes into the function must be listed
as a parameter and everything that goes out has to be in the output
list. This is a nice quality when you're debugging your code because
you know when things change. GUIs change this - and so does the use of
global variables. The use of set/get functions together with
setpref/getpref and setappdata/getappdata makes it possible to use
variables that are global to Matlab. This is generally not considered
as bad as "real" global variables since the way GUIs are normally
programmed you would not have conflicts between the properties of
different figures (and objetcs therein) although there is no way to
hide global variables from other applications, which lead to the
discussion of data hiding:
Absolutely anybody may change or delete your global variables! There
is no way to control this! It is difficult to debug when this happens!
I.e. global variables are only nice when you are entirely in control
and still remember when and where you put them in your code.
>4) using <global>s won't work in certain ML contexts, such as <gui
>callback>s (see the various ng posters)
For GUIs there's always better (although not perfect) alternatives.
>5) using <global>s actually is time consuming in ML (i don't know the
>reason for this):
[snipped]
Good point!
>hence, eventually collecting your <global>s into a <struct> (i.e.,
>cleaning up your <toolbox>) and passing it on as a parameter of your
><function>s is the most economic way to program stuff in ML ... and it
>shows your intelligence, to boot.
Even better!
Lars
M.Sc. Chem. Engng. Lars Gregersen
Dep. Chem. Engineering, DTU, Denmark
l...@kt.dtu.dk
http://gregersen.webjump.com
Scott Seidman
most convenient when you didn't know on calling exactly what data the
function needed. Once or twice, the most convenient way around this
situation was to use a script instead of a function. Once or twice, a
global declaration solved this nicely.
That said, problems like this haven't come up for me since Mathworks
incorporated the "evalin" function. Has anyone else noticed that globals
and scripts-instead-of-functions are easier to avoid?
Scott
"Lars Gregersen" <l...@kt.dtu.dk> wrote in message
news:3a2f42b7....@news.dtu.dk...