Maximizing Your Environment – Global Variables

Automation has been a powerful capability of IDEA from the beginning. Its main goal is to ease the auditing process, but its true value can only be fully appreciated when leveraged properly. A solution is only as good as its implementation and in this case, proper implementation will not only facilitate the steps of analysis but dramatically cut down the time required to perform the analysis; thereby creating opportunities for greater productivity.

For many tasks, IDEA’s Visual Script component will help. It’s a simpler, more direct way of creating scripted tasks that work with symbols rather than code. For more advanced tasks, it simply lacks too many features and full IDEAScript must be used. IDEA now offers two varieties of code (the original VBA and the newly added Python), but in either case, the user must be comfortable with the environment to make the most of it. Our objective is to provide topics that enable you to achieve that level of comfortability in the usage of your environment, as we all have different legacy systems, with similar areas.

This post focuses on the concept of global variables. Scope is an important programming concept that some people require a hand in grasping. It’s possible “global variables” and “scope” may have had no meaning to you just now. That’s perfectly fine as these guides will cover the topics from the ground up. To begin, consider the following short VBA script:

Sub Main

End Sub

An undeniably useless script, yes, but recall this is purely to explain the concept of scope. Given what a full user database would encompass (format checking, writing/reading files, error handling, etc.), it’s easy to imagine the script will become very large very quickly. Even in this short example, the beginnings of clutter can be seen as it’s all packed into a single method.
 
Very quick aside: Those of you already at least somewhat versed in scripting will likely point out that methods can be created to split up key tasks and cut down on clutter. To those users, global variables can cut down on the complexity of method signatures and decrease the Main method size (the entry point of the script), further by removing some (if not all, depending on the project) variables entirely.

A big part of creating (and then later, interpreting) scripts is readability. The hairier a script gets, the easier it is to induce a headache trying to piece it all together. Consider the following revised example:

Dim user As String

Dim department As String

Dim salary As Double

Sub Main

End Sub

Sub GetUserData

End Sub

Sub ProcessUserData

End Sub

Sub PrintUserData

End Sub

Right away, the Main method is noted to be very clean. It clearly lists the tasks that are being performed and the logic of those tasks is handled individually within their respective methods. This is an example of scope.

Consider scope to be a building in which people work. The tools required to accomplish their tasks will, of course, be housed in that building, but in scripting, it’s important to determine which tools need to be shared among the buildings. In the scope (building) of ProcessUserData, it of course needs access to the user data (tools). It may have a few of its own unique tools, as can be seen by the “benefits” array declaration, but this is because this is a tool that only ProcessUserData will use. No other method needs to even know it exists. That is what determines where variables are laid out.
 
For data that everyone needs to be able to access, it cannot be declared in any one building since it would mean that building owns the data. See how the original variable declarations were moved from Main to the very top of the script? Being at the very top is convention. It makes it easy to find all the variables by keeping them together as the first thing someone sees, but realistically as long as a variable is declared outside any and all methods it is considered to be global; of course, meaning it can be globally accessed by all the methods. Notice the methods did not repeat any of the global variable declarations. ProcessUserData could begin using “department” right away because it was within the global scope. Since “benefits” is declared only within ProcessUserData, attempted access from any other method will cause an error because it is not defined in scope.

VBA Quirk: Unless the “Option Explicit” directive is given at the top of the script, scoping will be very lax. Attempted use of a variable that is not in scope will simply create a new variable and scope it to the method it was used in. For example, trying to use “benefits” in Main will not access the “benefits” from ProcessUserData. It will generate a new variable called “benefits” that only works inside of Main. Most programming languages do not have this quirk, so it can be confusing for beginners. Other programming languages will specifically warn you that the variable cannot be found, thereby verifying you’re accessing what you meant to access. Be mindful that unless it is a global variable (properly declared outside all methods), using a variable across methods is not accessing the same block(s) in memory, regardless of whether the compiler flags it as an error or not.

Global variables are handy but they are certainly not a kind of “best practice.” Global variables are merely a technique at your disposal. Being aware of how scoping works means applying the right techniques for the job. Sometimes global variables are best. Sometimes values should be passed in method signatures. Sometimes those passed values should be returned or referenced directly for multiple returns (which carries its own debate in the developer community, but that is outside the scope of this blog post). Complex tasks will likely see data handled in all sorts of ways. There is no need to force a script to conform to anyone’s way of handling data.