Hi,
since global variables are seen as the big satan we have to control them.
One supporting attempt can be the output of a list of global variables by the compiler.
This option should also be possible to choose by the editor.
Greetings
LN
Compileroption: output of list of global variables
- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
-
- Addict
- Posts: 4777
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Compileroption: output of list of global variables
Global variables are not "the big satan", but the effort to maintain a program grows as the number of global variables grows.langinagel wrote:since global variables are seen as the big satan we have to control them.
One supporting attempt can be the output of a list of global variables by the compiler.
This is always the case, regardless whether or not the compiler is able to generate such a list. So it's generally recommendable to use global variables rarely, and to use them with care.
When you need such a list, there are likely far too much global variables in your program(s). Using global variables rarely in the first place is possible, and just a question of coding style. And with only half a dozen or less global variables in a program, no such list is needed.
Re: Compileroption: output of list of global variables
1) avoid global vars
2) use "Define" on global scope, and "shared" on local Scope, so you need global vars only in very special cases
3A) use modules and use only "modulwide" Variables, so you protect the other code from this vars
3B) generally make "modulewide" variables only public if this is realy needed
4) use a special polish notation for your globals (e.g. use "gvarname" instead of "varname", or in a module use "_varname", "m_varname2 or "myvarname" instead of "varname"
2) use "Define" on global scope, and "shared" on local Scope, so you need global vars only in very special cases
Define gvarname
Procedure test()
Shared gvarname
ProcedureReturn gvarname
endprocedure
3A) use modules and use only "modulwide" Variables, so you protect the other code from this vars
3B) generally make "modulewide" variables only public if this is realy needed
4) use a special polish notation for your globals (e.g. use "gvarname" instead of "varname", or in a module use "_varname", "m_varname2 or "myvarname" instead of "varname"
-
- Enthusiast
- Posts: 443
- Joined: Sun Apr 06, 2008 12:54 pm
- Location: Brisbane, Qld, Australia
- Contact:
Re: Compileroption: output of list of global variables
Personally I use global variables quite extensively, but I have them all defined in a single include file, and the name of every global variable starts with "g".
Re: Compileroption: output of list of global variables
Today I learned I must prefix all my Global vars/strucs/constants/arrays/maps with 'evil_myVar'. 

The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
Re: Compileroption: output of list of global variables
Fine,
we all learned now how to deal with global variables on an operational point of view (care for this, do that,..).
Maybe the requested function might as well be useful for those beginners or hobby-programmers who are not full aware what kind of variables are treated as global by the compiler and what are not.
Second attempt.
Greetings
LN
we all learned now how to deal with global variables on an operational point of view (care for this, do that,..).
Maybe the requested function might as well be useful for those beginners or hobby-programmers who are not full aware what kind of variables are treated as global by the compiler and what are not.
Second attempt.
Greetings
LN