pic
Personal
Website

3d. Variable Scope & Relevance of Functions

Martin Alfaro
PhD in Economics

Introduction

Variable scope refers to the code block in which a variable is accessible. The concept allows us to distinguish between global variables, which are accessible in any part of the code, and local variables, which only exist within a specific code block. The existence of scopes determines that the same variable x could refer to different objects, depending on where it's called.

When it comes to functions, Julia adheres to specific rules for variable scope. Specifically, given a variable x defined outside a function:

  • if a new variable x is defined inside a function or is passed to the function as an argument, then x is considered local to that function. Moreover, any reference to x within the function refers to the local variable, without any relation to the variable x defined outside the function,

  • if the function includes x, but it doesn't define a new x nor x is a function argument, then x refers to the variable defined outside the function (i.e., the global variable).

The rules can be more effectively understood by illustrating them, as we do next.

Global and Local Variables

A variable that is local to a function only exists within the function's scope. Consequently, if we attempt to reference it outside the function, Julia will indicate that the variable doesn't exist.

Variables local to a function encompass: i) the function arguments, and ii) variables defined in the function body. Any other variable appearing in a function necessarily refers to a global variable.

Identifying local variables in a function is crucial, as a local variable may share the same name as a global variable without them being related. The distinction between global and local variables is easier to grasp through the following examples.

x = "hello"

function foo(x)                # 'x' is local, unrelated to 'x = hello' above
    y = x + 2                  # 'y' is local, 'x' refers to the function argument 
    
    return x,y
end

Output in REPL
julia>
foo(1)
1 # local x 3 # local y

julia>
x
"hello"

julia>
y
ERROR: UndefVarError: y not defined

z = 2

function foo(x)                 
    y = x + z                   # 'x' refers to the function argument, 'z' refers to the global

    return x,y,z
end

Output in REPL
julia>
foo(1)
1 # local x 3 # local y 2 # global z

julia>
x
ERROR: UndefVarError: x not defined

julia>
z
2

The Role of Functions

A function should be understood as a self-cointained mini-program to represent a specific task. Under this interpretation, local variables simply act as labels that help articulate the mechanics of the task. Indeed, variables local to a function are inaccessible outside of it. [note] Local variables play a similar role to integration variables in math. Formally, \(t\) in \(\int f\left(t\right)\,\mathrm{d}t\) for some function \(f\) is just a symbol indicating over which variable we're integrating. This is why the integral can be equivalently expressed through \(x\), as \(\int f\left(x\right)\,\mathrm{d}x\), or any other label for \(t\).

To explain what this means, consider the existence of a variable x, and another variable y computed by transforming x through the function f. Formally, y = f(x), where we directly assume that the transformation doubles x, so that y = 2 * x. The following are two approaches to computing y.

x = 3

double() = 2 * x
y        = double()

x = 3

double(x) = 2 * x
y         = double(x)

x = 3

double(πŸ’) = 2 * πŸ’
y          = double(x)

The function in Approach 1 utilizes the global variable x. This practice is highly discouraged for several reasons. Firstly, it prevents the reusability of the function, as it's specifically designed to double the global variable x, rather than acting as a mini-program that doubles any variable.

Second, the inclusion of the global variable x compromises the function's self-containment, as the function's output depends on the value of x at the moment of execution. If you work on a long project, this feature makes the code more prone to bugs.

Lastly, global variables have a detrimental impact on performance, a topic we'll study later on the website. In fact, global variables in Julia are directly a performance killer.

In contrast, Approach 2 refers to x as a local variable. This x is unrelated to the global variable xβ€”it simply serves as a label to identify the variable to be doubled. Indeed, we could've replaced it with any other label, as demonstrated in Approach 3 through the monkey emoji, πŸ’.

By avoiding referencing any variable outside its scope, Approach 2 makes the function self-contained. This allows users to predict the consequence of applying double by simply inspecting the function, eliminating the need to review the entire codebase. Thus, Approach 2 aligns with the interpretation of a function as a self-contained mini-program: the function embodies the task of doubling a variable, turning the function reusable and applicable to any variable. In this context, applying double to the global variable x is just one possible use case.

Recommendations For The Use Of Functions

Structuring code around functions offer numerous advantages. However, to fully realize these benefits, it's essential to follow certain principles when writing code. This section outlines a few of them, and should be considered as a mere introduction to the subject. The topic will be investigated further, when we explore high performance.

Avoid Global Variables in Functions

Global variables are strongly discouraged. This is not only due to the reasons mentioned previously, but also because they can have a devastating impact on performance. The easiest solution to this issue is to pass global variables as function arguments. This practice will actually become second nature once you start viewing functions as self-contained mini-programs. Specifically, by adopting this perspective, you'll conceive local variables as labels to describe a task, rather than references to global variables. This shift in mindset can help you write more efficient and maintainable code.

Avoid Redefining Variables within Functions

The suggestion applies to both local variables and function arguments. Redefining these variables can have several disadvantages, including reduced code readability and potential performance degradation. Therefore, it's recommended that you define new variables instead of redefining existing ones. This approach is demonstrated in the following example.

function foo(x)
   x      = 2 + x           # redefines the argument
   
   y      = 2 * x
   y      = x + y           # redefines a local variable
end

function foo(x)
   z      = 2 + x           # new variable
   
   y      = 2 * x
   output = z + y           # new variable
end

×

Another Issue of Redefining Variables

Within a function, Julia will throw an error if you perform a computation using a global variable x and then redefine x. For example:

Code 

x = 2

function foo()
    y = x + 2
    x = x + 4

    return x
end

Output in REPL
julia>
foo()
ERROR: UndefVarError: x not defined

The error arises because Julia reads the entire function before its execution: the function's second line assigns a value to x, causing Julia to consider x a local variable. The consequence is that, when the function is run, x in y = x + 2 is interpreted as a local variable that hasn't been defined yet.

Modularity

We've emphasized the importance of viewing functions as self-contained mini-programs, designed to perform specific tasks. This perspective leads us to highlight the importance of modularity: the practice of breaking down a program into multiple small functions, each with its own distinct purpose, inputs, and outputs.

The primary benefit of modularity is the ability to work with independent code blocks. By keeping these blocks separate, we can decompose complex problems into multiple manageable tasks, making it easier to test and debug code. Additionally, modularity makes it possible to eventually improve or substitute parts of the code, without breaking the entire program.

A helpful way to understand this principle is by considering the analogy of building a Lego minifigure. In the first step, multiple blocks are created independently, each representing a specific part of the figure, such as the legs, torso, arms, and head. Then, in the second stage, these individual blocks are brought together and assembled into an integrated minifigure.

This two-step approach offers several advantages. By focusing on each block individually, we can concentrate and refine each part without worrying about the entire structure. Additionally, it provides great flexibility: since each block is created independently, we can modify specific blocks without having to rebuild the entire figure. For instance, if we want to change the figure's head, we can simply swap out the corresponding block, without starting from scratch.

The principle of modularity is closely tied to the suggestion of writing short functions. Some proponents even argue that functions should be limited to fewer than five lines of code Indeed, entire books have been written based on this principle. Although this viewpoint may be considered rather extreme, it clearly emphasizes the advantages of avoiding lengthy functions.

×

Example of Modularity

Coming up with mock scenarios illustrating the advantages of modularity can be tricky. This occurs because the same function could be deemed modular enough, depending on the context and your goals. Moreover, modularity may become detrimental if it impairs code readability. On top of this, note that making code more modular may not be justified if there aren't plans to reuse it.

With these challenges in mind, we'll present an example that showcases the potential benefits of modularity. The example focuses on calculating the cost of purchasing a product, when this is subject to a percentage tax over the total value. Specifically, consider the following two scripts to compute this.

expenditure(price, quantity, tax_rate) = price * quantity * (1 + tax_rate)

value_before_taxes(price, quantity)       = price * quantity
valueAdded_tax(price, quantity, tax_rate) = price * quantity * tax_rate     #it'll define the variable 'tax_paid'

expenditure(price, quantity, tax_paid) = value_before_taxes(price, quantity) + tax_paid

Consider now a scenario where an iPhone has a price of 1,000 USD and a tax rate of 5%. Then, we can apply these two mini-programs to compute the total expenditure of purchasing two iPhones. 

#functions to compute expenditure
expenditure(price, quantity, tax_rate) = price * quantity * (1 + tax_rate)




#information 
price    = 1000
quantity = 2
tax_rate = 5 / 100

#computation
expenditure_iPhones = expenditure(price, quantity, tax_rate)

Output in REPL
julia>
expenditure_iPhones
2100.0

#functions to compute expenditure
value_before_taxes(price, quantity)       = price * quantity
valueAdded_tax(price, quantity, tax_rate) = price * quantity * tax_rate

expenditure(gross_value, tax_paid) = gross_value + tax_paid

#information 
price    = 1000
quantity = 2
tax_rate = 5 / 100

#computation
gross_value         = value_before_taxes(price, quantity)
tax_paid            = valueAdded_tax(price, quantity, tax_rate)

expenditure_iPhones = expenditure(gross_value, tax_paid)

Output in REPL
julia>
expenditure_iPhones
2100.0

While approach 2 is more verbose, it's also more readable, allowing the user to quickly understand the code's purpose. In contrast, Approach 1 requires the reader to carefully examine each term of expenditure to decipher its meaning.

Furthermore, Approach 2 is more modular, as it breaks down total expenditure into two distinct components: the money to purchase the product without taxes and the taxes paid. While the benefits of this may not be immediately apparent in such a simple example, they would be easily appreciated in a more complex scenario. There are several reasons for this.

First, Approach 2 offers greater flexibility compared to Approach 1. It can easily accommodate scenarios with multiple taxes or taxes of different forms, simply by recomputing tax_paid. In contrast, fitting new cases through Approach 1 would necessitate modifying the entire script, including a full redefinition of expenditure and its components. Second, Approach 2 is more convenient for testing code blocks separately. This feature is critical for ensuring proper code functioning, and can additionally simplify code debugging and the identification of performance bottlenecks.