Jump to content

Why use Local and Global at all?


WRP
 Share

Recommended Posts

A variable declared within a function is automatically Local. Anything declared outside a function is automatically Global, even if it was declared Local, since there is no file scope. As for declaring Global within a function, that's just a bad idea. So is there really any benefit to having the Local/Global declarations?

 

Link to comment
Share on other sites

  • Moderators

WRP,

I believe so - declaring the scope implicitly makes sure that the coder fully realises the scope for that particular variable/constant.

M23

Public_Domain.png.2d871819fcb9957cf44f4514551a2935.png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind

Open spoiler to see my UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Link to comment
Share on other sites

I have tried writing scripts without Local/Global and everything seems to work fine. I would expect there to be problem situations, though, since the single equals sign is overloaded as both assignment and test. Can you think of example cases where omitting Local/Global would break the code?

Link to comment
Share on other sites

Plenty!

This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Link to comment
Share on other sites

To prevent crude, unsophisticated and extremely limited functionality; we use scoping. The following is a crude demonstration of a local / global collision. Sure it's possible to write code like this, but once you start working on larger projects you don't want to have to keep tabs on all the possible collisions.

$i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    $i = 1
EndFunc

The best way to avoid collisions is to always try to use local variables. Sometimes achieving this can present a bit of a challenge; but it's a very flexible, and certainly the safest, approach. So now we can write this:

Local $i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    Local $i = 1
EndFunc

Both the variable declarations in the above example are correct, but there is a potential problem. The first (local) declaration of $i produces a global variable by default, because it was not declared within the function blah(). The second declaration produces a local variable because it was declared as a local variable within the function blah(). To ease the mind (but not necessarily the conscience), we can make the code easier to understand by being more explicit and use the keyword Global for the first declaration. Doing so doesn't change the outcome or reduce the risk of a collision.

Global $i = 0
ConsoleWrite(blah(blah(blah(''))) & $i & @LF)

Func blah($_)
    Local $i = 1
EndFunc

The above code is not a good example because it is quite meaningless and does not actually need to use any variables at all.

ConsoleWrite(blah(blah(blah(''))) & 0 & @LF)

Func blah($_)
EndFunc

 


So why use global variables?

One example of good usage is when you want to share data between several scripts (and other developers). Perhaps the data is a constant like Pi: two letters being easier to remember than a larger number of digits. In all cases, using global variables runs the risk of encountering collisions. Using long and unusual variable names reduces the likelihood of a collision but makes the code harder to read. All considerations / trade-offs need to be kept in perspective. Explicitly declaring local variables within functions prevents collisions, which I assume is the main objective.

Edited by czardas
Link to comment
Share on other sites

13 hours ago, WRP said:

Anything declared outside a function is automatically Global, even if it was declared Local, since there is no file scope.

There's a caveat to this (incidentally, one that is not mentioned in that Best coding practices that czardas just linked to), in that a For variable inside a function with the same name as an existing global variable is treated as a different, purely local variable. This will be more obvious when explicitly (re)declared. Example:

Global $myGlobalVar=123
Consolewrite("value before call " & $myGlobalVar & @CRLF)
_MyFunc()
Consolewrite("value after call " & $myGlobalVar & @CRLF)

Func _MyFunc()
    ;Global $myGlobalVar    ; even if explicitly declared as global here, it's still redeclared local by For
    For $myGlobalVar=1 to 3
        consolewrite("value in func " & $myGlobalVar & @CRLF)
    Next
EndFunc

So usage of For <var>=x to y inside a function also makes that var Local, even if it has previously been declared as having global scope, and even if it is redeclared as Global inside that function beforehand. I ran into this when I tried to use a For loop inside a function to try and adjust a global variable's value, which turned out to be a terrible idea.:rolleyes: So all the more reason to always explicitly declare, if only to keep conscious track of scope (and make the code easier to read for your future self, and others).

Edited by RTFC
Link to comment
Share on other sites

@czardas: Yeah, it wasn't a particularly bright design concept on my part, I agree:D. But I figured that an explicit global declaration in <main> would always trump any explicitly undeclared var's scope inside a func. My bad, of course.^_^

Edited by RTFC
Link to comment
Share on other sites

The Help file text of the For statement does mention it, but of course I didn't read up on it, I just tried and watched it fail horrendously. And not having explicitly declared the var local in the func, I assumed it would remain Global there (NOT). I'm just glad I don't work for NASA...:baby:

Link to comment
Share on other sites

11 hours ago, czardas said:

Explicitly declaring local variables within functions prevents collisions...

I understand the argument of using Local/Global for code readability, but I don't see it for avoiding collisions.

As far as I can tell, except for the case of Global within a function, AutoIt assigns the same scope to variables whether or not Local/Global is used. So, Local should have absolutely no effect wherever it is used.

Link to comment
Share on other sites

26 minutes ago, WRP said:

I understand the argument of using Local/Global for code readability, but I don't see it for avoiding collisions.

As far as I can tell, except for the case of Global within a function, AutoIt assigns the same scope to variables whether or not Local/Global is used. So, Local should have absolutely no effect wherever it is used.

Is it hard for you to imagine something like this?

$i = 5

SomeFunction()

MsgBox(4096, "Aha", "$i = " & $i)



Func SomeFunction()
    $i = 4096
    $y = 2

    MsgBox($i, "...", "wait a bit", $y)
EndFunc

Try adding "Local" for variables inside the function to see if there'd be any changes.

Anyway, variables used only inside a function should be declared as local, not because of readability, but because of correctness. czardas already explained.

Edited by trancexx

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

OK, so the explanation I needed is that without Local/Global, the default behavior is to make a variable declared within a function local UNLESS the name refers to an existing global variable. So the use of Local prevents reference to an existing global variable.

 

Link to comment
Share on other sites

That is correct, and is explained in the help file.

If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Link to comment
Share on other sites

1 hour ago, WRP said:

OK, so the explanation I needed is that without Local/Global, the default behavior is to make a variable declared within a function local UNLESS the name refers to an existing global variable. So the use of Local prevents reference to an existing global variable.

 

If one uses the best practice of having a "g" in the name of global variables, then, collisions would not happen.

Link to comment
Share on other sites

14 hours ago, czardas said:

thanks - 

Is there any interest in including a recommendation to use the "p" for parameters?
They are different from local variables in the that they can be changed and cause a side effect change back in the calling function or mainline code.

Link to comment
Share on other sites

2 hours ago, philkryder said:

thanks - 

Is there any interest in including a recommendation to use the "p" for parameters?

Parameters are treated as local variables unless you use the ByRef keyword, so function parameters do not collide with global variables. Remove ByRef from the code below and the global variable will remain zero. Also, scroll up the best coding practices page and you will see that the letter p is already used to indicate a pointer.

Global $g_iParam = 0

Go($g_iParam)
MsgBox(0, "", $g_iParam)

Func Go(ByRef $g_iParam) ; Remove ByRef to test the difference.
    $g_iParam = 1
EndFunc

 

Edited by czardas
Link to comment
Share on other sites

16 hours ago, philkryder said:

Is there any interest in including a recommendation to use the "p" for parameters?

No, as p already has a meaning

UDF List:

 
_AdapterConnections()_AlwaysRun()_AppMon()_AppMonEx()_ArrayFilter/_ArrayReduce_BinaryBin()_CheckMsgBox()_CmdLineRaw()_ContextMenu()_ConvertLHWebColor()/_ConvertSHWebColor()_DesktopDimensions()_DisplayPassword()_DotNet_Load()/_DotNet_Unload()_Fibonacci()_FileCompare()_FileCompareContents()_FileNameByHandle()_FilePrefix/SRE()_FindInFile()_GetBackgroundColor()/_SetBackgroundColor()_GetConrolID()_GetCtrlClass()_GetDirectoryFormat()_GetDriveMediaType()_GetFilename()/_GetFilenameExt()_GetHardwareID()_GetIP()_GetIP_Country()_GetOSLanguage()_GetSavedSource()_GetStringSize()_GetSystemPaths()_GetURLImage()_GIFImage()_GoogleWeather()_GUICtrlCreateGroup()_GUICtrlListBox_CreateArray()_GUICtrlListView_CreateArray()_GUICtrlListView_SaveCSV()_GUICtrlListView_SaveHTML()_GUICtrlListView_SaveTxt()_GUICtrlListView_SaveXML()_GUICtrlMenu_Recent()_GUICtrlMenu_SetItemImage()_GUICtrlTreeView_CreateArray()_GUIDisable()_GUIImageList_SetIconFromHandle()_GUIRegisterMsg()_GUISetIcon()_Icon_Clear()/_Icon_Set()_IdleTime()_InetGet()_InetGetGUI()_InetGetProgress()_IPDetails()_IsFileOlder()_IsGUID()_IsHex()_IsPalindrome()_IsRegKey()_IsStringRegExp()_IsSystemDrive()_IsUPX()_IsValidType()_IsWebColor()_Language()_Log()_MicrosoftInternetConnectivity()_MSDNDataType()_PathFull/GetRelative/Split()_PathSplitEx()_PrintFromArray()_ProgressSetMarquee()_ReDim()_RockPaperScissors()/_RockPaperScissorsLizardSpock()_ScrollingCredits_SelfDelete()_SelfRename()_SelfUpdate()_SendTo()_ShellAll()_ShellFile()_ShellFolder()_SingletonHWID()_SingletonPID()_Startup()_StringCompact()_StringIsValid()_StringRegExpMetaCharacters()_StringReplaceWholeWord()_StringStripChars()_Temperature()_TrialPeriod()_UKToUSDate()/_USToUKDate()_WinAPI_Create_CTL_CODE()_WinAPI_CreateGUID()_WMIDateStringToDate()/_DateToWMIDateString()Au3 script parsingAutoIt SearchAutoIt3 PortableAutoIt3WrapperToPragmaAutoItWinGetTitle()/AutoItWinSetTitle()CodingDirToHTML5FileInstallrFileReadLastChars()GeoIP databaseGUI - Only Close ButtonGUI ExamplesGUICtrlDeleteImage()GUICtrlGetBkColor()GUICtrlGetStyle()GUIEventsGUIGetBkColor()Int_Parse() & Int_TryParse()IsISBN()LockFile()Mapping CtrlIDsOOP in AutoItParseHeadersToSciTE()PasswordValidPasteBinPosts Per DayPreExpandProtect GlobalsQueue()Resource UpdateResourcesExSciTE JumpSettings INISHELLHOOKShunting-YardSignature CreatorStack()Stopwatch()StringAddLF()/StringStripLF()StringEOLToCRLF()VSCROLLWM_COPYDATAMore Examples...

Updated: 22/04/2018

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...