Sign in to follow this  
Followers 0
WideBoyDixon

Cutting down on global variables

17 posts in this topic

In a few scripts that I've written recently I've needed to hold some global variables but I don't like doing so if I can avoid it. Can anyone think of a good reason why I shouldn't use DllStructCreate and then store all my strings and numbers in one global structure rather than having multiple global variables to achieve the same thing? Just curious because it seems like the most elegant solution to me.

WBD

Share this post


Link to post
Share on other sites



Why would you say the global variables are evil??

I'm creating them in the global scope or declaring them global on a "need basis"; that is, if the variable need to be used in more than one function I have to make it global (yeah, I know I can use function return and such ... but that looks like an unnecessary complication).


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

The most elegant solution would obviously be to use array(s).


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

The most elegant solution would obviously be to use array(s).

Arrays, in some cases, are less convenient than the structure.

MyStruct DllStruct
    Int Data
    char[256] String
EndDllStruct

http://www.autoitscript.com/forum/index.php?s=&showtopic=92012&view=findpost&p=662081

To be honest, this is sometimes not enough.

:)

Edited by Yashied

Share this post


Link to post
Share on other sites

Still nobody answered why global variables are considered "evil" :)


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

The public-ness of them is evil. Any include may be modifying your globals. You might accidentally modify your include's variables. There isn't a way to share data between only specific functions yet.

Share this post


Link to post
Share on other sites

Aww phooey. What I really want of course is the ability to use a struct or a class but I know that's not coming to AutoIt. Passing arrays around is OK but then I need to keep track of which array element corresponds to which value. I also don't get strongly typed variables this way whereas I could in a DllStruct. I'll go away and think around the problem some more and perhaps find a way to give myself less exposure on the Global variables front.

WBD

Share this post


Link to post
Share on other sites

You could make a global variable and use a COM dictionary object.

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

Aww phooey. What I really want of course is the ability to use a struct or a class but I know that's not coming to AutoIt. Passing arrays around is OK but then I need to keep track of which array element corresponds to which value. I also don't get strongly typed variables this way whereas I could in a DllStruct. I'll go away and think around the problem some more and perhaps find a way to give myself less exposure on the Global variables front.

WBD

I usually write my scripts like this when I want to avoid magic numbers in arrays (especially 2D arrays), it makes it a lot more readable.

Global Const $_NAME=0, $_AGE=1, $_COUNTRY=2
Global $Array[3]

$Array[$_NAME]="Andreas"
$Array[$_AGE]=18
$Array[$_COUNTRY]="Sverige"
Edited by monoceres

Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

Still nobody answered why global variables are considered "evil" :)

Personnally I don't consider global variables to be bad. If you name them carefully the chance of conflicts with includes is very small IMO. I don't know how to use registered messages which have to relate to certain controls or windows without global variables, and when you pass messages to another window it can also be difficult without using global variable even it if it is just an array.

As far as I see it, all controls and windows which have been created are really global variables anyway. The problem is when you come to use them in functions and then I think that you should use them as little as possible and preferably never. The reason for that it so that you can use a function in any script and you can more easily test a function before you use it in your main script. Also, if you pass all the data to a function that it needs using parameters rather than letting it use global variables youknow exactly what that function is dealing with. I think that is where global variables have got their bad reputation because if you put a function which uses global variables into a new script then its chaos.

It would be nice if we could natively create objects in AutoIt which had properties and functions/methods and that might remove a lot of the need for global variables.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

I usually write my scripts like this when I want to avoid magic numbers in arrays (especially 2D arrays), it makes it a lot more readable.

Global Const $_NAME=0, $_AGE=1, $_COUNTRY=2
 Global $Array[3]
 
 $Array[$_NAME]="Andreas"
 $Array[$_AGE=18
 $Array[$_COUNTRY="Sverige"
I agree that is the best way to do it. It is certainly more readable in the example you gave, but I don't think the reliability would be too good the way you wrote it :)

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

Oh, btw, here's my top tree against global variables.

  • Messy, makes the script hard to read/maintain
  • Eats up the namespace, reserves the name for the entire script, this makes writing functions harder since you sometimes cannot use good names for the local variables.
  • Breaks any form of modularized structure, I like the idea of each function doing its task without getting involved in the actions of its neighbour functions. It's hard to maintain that when functions share the exact same data.

However I still use global variables to much when I'm writing code in autoit. Why? Because I find it the easiest way to go since I lack some tools that I usually use (OOP for example).


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

I agree that is the best way to do it. It is certainly more readable in the example you gave, but I don't think the reliability would be too good the way you wrote it :)

Well of course you need to enforce some kind of naming convention for the constants so they are unique throughout the script.


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

Maybe we should all get our own "namespace" for global variables so all mine will start with $gWBD...

:)

Share this post


Link to post
Share on other sites

You can always do things like that.

$richardsglobalvariablesbeginwiththis_MyVariable1

Share this post


Link to post
Share on other sites

I completely agree with martin: if you name them carefully then it will never conflict with includes or such; that's why I don't use short names for any of my variables and every global variable name has a part relating to the script name.

Also, I declare them at the begining of the script in a "Global Var" block so I know at any time where I can find them.

I don't consider them "evil" at all.


SNMP_UDF ... for SNMPv1 and v2c so far, GetBulk and a new example script

wannabe "Unbeatable" Tic-Tac-Toe

Paper-Scissor-Rock ... try to beat it anyway :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0