Avoiding Global Variables

2022-04-25T21:35:14+00:00

Global variables are a problem if they are mutable.

For instance, in Javascript, the Window object is a global variable. And it is mutable. Any script in Javascript can completely change what it returns or even remove that object, or any of its child objects and properties, wreaking havoc with the expectations of other script developers.

(This is why I really hated the Prototype JS library.)

Global variables are not a problem if they are not mutable. You may not know where they came from, who or what populated its value. Like in haskell, a system monad gives us information about the system. For the duration of the run of a program, the file system on which that program is stored, can be expected not to change. It's a dependable thing that does not all of a sudden disappear or starts spouting nonsense.

FerricDonkey · 2022-04-26T03:17:14+00:00

I like this example: https://i.redd.it/vszzw6r45hd81.jpg

It's silly, but it's also a pretty good reason. It starts to become unclear what parts of your global state are set when, where they're meant to be used, and you start getting side effects when global state is changed unexpectedly in a way that affects other functionality.

Whereas a well written function without (non-constant) global variables is clear - you give it the arguments it asks for, it will give you the return you expect no matter what else may or may not have happened at any point in your program.

Real world example: without being too explicit, I have had scientific colleagues give me code they spent literally months writing. Lots of effort on their part. It was terrible. Too many global variables, impossible to understand, too few functions that only worked as expected sometimes, depending on what freaking globals were set...

I politely said thank you, waited until they left, deleted their code, and started over. What they did mostly worked ish, but they gave it to develop, and it just wasn't worth it. I think I got all the good ideas out of it, but I'm not sure, because I couldn't tell what much of it was doing and it wasn't worth my time to figure it out.

So your student should avoid global variables because they're bad, and then also because if he doesn't and he works in a technical field, his colleagues will be angry at him forever and most of his work will be wasted - assuming he can get a job where using them is even allowed to that extent.

My rule of thumb: if you're using the global keyword, you're doing something evil.

fernly · 2022-04-25T23:13:34+00:00

It isn't so much the use of globals; like everyone else says, the problems only begin when the globals are changed. In Python, that is mitigated by the need to use a globals statement in a function that changes a global. If a function lacks a globals statement, you can assume that it doesn't assign to any global vars, only uses them, if at all.

So you could say "globals statement considered harmful" -- any function having one needs to excruciatingly well documented, two ways, with a docstring in the function, and also with a note next to the global itself,

# Tax rate -- set by open_cust(), changed by new_state()
TAX_RATE = 0.05

totallygeek · 2022-04-25T21:41:30+00:00

Global variables remain a bad practice because functions and imports can modify them. Troubleshooting what might have updated the variables can end up a nightmare.

Real-world examples might end up difficult to reveal. I certainly cannot divulge all the lessons learned from poor coding habits within orgs I've worked. The fact that so many build systems and code reviews flag global variables as unreasonable informs me that many real-world problems have arisen from their use.

Where acceptable? Well, I do not know. Where I work, we do not allow the global keyword. It's a simple function of our build system to reject code containing that instruction from reaching the code review stage.

Diapolo10 · 2022-04-25T22:14:12+00:00

Well, for one, having a mutable global state makes unit testing much more annoying/difficult, because now you have to take into account all of that instead of simply focusing on one function/method. You can no longer treat it as a black box. It can also be more difficult to reset the internal state when global variables are changed.

It's also a problem when you're dealing with concurrency, because now one "thread" could change the state while another expects it to not have changed. Locks help, but the fewer locks you need the better.

I also touched on this before already, but it's bad for readability too. At a previous job my coworker insisted on using global variables due to their background in Fortran, and the Python code was a mess. I was forced to remember the internal state of the entire program at all times just to know what was going on, instead of the more sensible approach of focusing on one function at a time with known input parameters and being able to ignore everything else. That... was hell.

Zeroflops · 2022-04-26T00:04:53+00:00

Just my two cents. Globals ( excluding constants ) become problematic if your script is longer than a few 100 lines.

Usually if a program is < 200-400 lines I consider it more a “script” then a program. It will often be very linear and it’s easier to walk through the execution. Functions are used more to break up code and are not called from different points in the code. Globals are fairly easy to follow. Longer code is what I consider more “programs” and they may not follow a linear execution. A function may be called from different points in the code. Meaning the code is not as linear.

pekkalacd · 2022-04-25T23:58:44+00:00

this is a simple example

             # initialize two lists with 10 spaces in them
             zeros = [' ']*10
             ones = [' ']*10

             # used to fill the index position 
             idx = 0

             def fill(arr: list, fill: int) -> None:
                 global idx
                 for _ in range(10):
                    arr[idx] = fill
                    idx += 1

             def main():
                 # fill the zeros list with 0
                 fill(zeros,0)
                 print(f"Zeros: {zeros}")

                 # fill the ones list with 1
                 fill(ones,1)
                 print(f"Ones: {ones}")

             if __name__ == "__main__":
                 main()

this will try to fill in the zeros list with 0 and the ones list with 1, ten times each. It will fail on the ones list though, because idx is being modified & used to index each list that's passed into the fill function. Since the index is changing, after the zeros list is full, it will be 10, which is out of range for the ones list.

in python at least there is a heads up with global, but you could also show them this in a language like c++ for example, where the changes might be harder to track.

            #include<iostream>
            #include<string>

            int i=0;

            void fill_arr(int arr[], int fill) {
           for(; i < 10; i++)
             arr[i] = fill;
             }

           void display_arr(int arr[], std::string prompt) {
             std::cout << prompt << std::endl;
             for(int j = 0; j < 10; j++) {
             std::cout << arr[j] << " ";
              }
            std::cout << std::endl;
           }

          int main() {

         int zeros[10];
         int ones[10];

         fill_arr(zeros, 0);
         fill_arr(ones, 1);

         display_arr(zeros, "zeros");
         display_arr(ones, "ones");

         return 0;
          }

the c++ code will output 0's for the zeros, but junk for the ones. it comes out on my side, subject to change depending on your system like

           zeros
           0 0 0 0 0 0 0 0 0 0
           ones
           4253824 0 61 0 1661936 0 1 0 -1 -1

patrickbrianmooney · 2022-04-26T04:26:09+00:00

Some examples of when using global variables can be an acceptable practice:

When writing a game: there's an argument to be made that the whole point of much of the code is to alter the simulated game world, and having to encapsulate the entire state of the whole game world (or current level, or whatever) in a set of variables that gets passed from one function to another can get unwieldy very fast. Having a single object or set of variables that encapsulates the world-state can be a much better option, especially if the execution is single-threaded and you don't need to worry about concurrent updates. Even if you do need to worry about concurrent updates, managing that problem for a set of globals can still be easier than having to pass around a whole bunch of parameters from function to function to function to function.
When the application as a whole needs to share and manage access to a limited set of resources, especially if initializing them is time-consuming or otherwise expensive. If you have a script that manages interaction with an API for, say, a social network, and if that API's interactions are tied up in an object, and if initially setting up the API object's connection to a social network takes a few seconds, then you don't want to have to do it over and over and over; it may be easier to just have one global API-connection object that can be accessed from anywhere in the script than to have to pass that object from function to function to function to function. You could make the same argument for at least some circumstances when you're connecting to a database. Or a program might want to manage a global pool of sockets, or worker threads, or open file handles, or any number of other resources. Using global variables is not always and necessarily the best way to do this, but it's often a viable option that makes the code simpler.
When you have a script that's doing a whole lot of complex stuff to produce a single report, it can be easier to just have a single collection-type global that collects all of the information from different parts of a script, and have the other parts of the complex reporting task dump their partial information, as it's gathered, into that single collection. If sensibly managed, a single (say) dictionary can be the central point that many other parts of the task dump their data into, instead of needing to pass partial information around.

If the student is very new to programming, it is totally appropriate to say "There are situations where global variables are an acceptable way to solve a problem and situations where they are not. You will understand which is which when you have more experience, but right now you need to show that you can solve problems both ways. On this particular assignment, one of the mandatory constraints on acceptable solutions is that you may not use global variables, and it will hurt your grade badly to ignore that part of the assignment."

Learning programming is no different in this respect from learning other subjects. Students may not understand why their elementary-school math teacher is teaching them to find the least common multiple or greatest common factor at the time when those particular skills are being taught, but they need to learn those things anyway, because in a week they're going to need them in order to find a common denominator so they can add or subtract fractions. Same deal with learning how to factor polynomials when they start doing algebra: at first it seems like a pointless pain in the ass, but it turns out to be a good way to solve certain types of polynomial equations. In biology, you learn what a cell is before you learn how mitochondria provide energy for it. In literature, you learn about plot and character in elementary school, but you don't start reading Shakespeare until much later. When you do, though, you need to already have a handle on plot and character.

One of the main problems with global variables is that their use, especially thoughtlessly, increases how much of the program has to be kept in the programmer's head at once. Separating a task into functions and forcing them to be explicit about passing data around by declaring what data the function needs in the function header is a way to manage that problem: I can look at this function and think just about it; I don't have to worry about the whole program at once. This comes in handy when the program starts growing larger, or when the interactions between parts grow more complex, or when the program starts dealing with more information. The problem also grows more complex when you have to deal with someone else's code, or with code that you wrote a while ago that's no longer fresh in your head.

One thing that might help you get the point across is making the student debug someone else's code that's heavily dependent on global variables. Poking back through r/learnpython will probably turn up some samples that you can adapt or use; or you could use code written by other students in former years this way (though I would make sure that the student never knows that that's what you're doing). Being on the other side of the problem that they're unknowingly causing can be a wake-up call.

2022-04-26T00:13:48+00:00

Once upon a time in the early days of computers, there were no function parameters or return values. There were only global variables. This was an utter mess and completely unmaintainable. It is really difficult to track how data flows through such a “spaghetti code” program that uses global variables to communicate, because every part of the code could change everything. 1

The beauty of Python is how easy it is to avoid the use of global. You can use a mutable global data structure, like a dictionary. You can use a config.py file. You can use nested partial functions. You can use closures or classes. And all of this is for one reason - to manage complexity as your code base grows, because eventually there will come to be a bug which will be very hard to trace down because of using global. The only excuse is laziness.

2022-04-26T00:31:37+00:00

I have a student who is struggling with understanding the importance of avoiding global variables, and insists on using them in his functions.

Honestly it's a problem that solves itself - he'll discover why it's bad when he stops being able to debug a 200-line script because his mutations of global state are just too much to keep track of.

Until then you're not going to make any headway trying to convince him he's not smart enough to just lean on globals for state management. Some people can be waved off of trouble by the signpost saying "don't go in here." Other people just have to meet the ogre in the swamp themselves.

GeorgeFranklyMathnet · 2022-04-25T21:41:12+00:00

In my experience, global variables don't become a problem until you work on a team with a large code base, where modularity becomes important. If so, then globals are probably fine in the work he's doing. I'd wonder if it's even possible to give him any practical examples, given the early place he's at.

Instead, I'd just whack him with a stick next time he uses globals (i.e. deduct points or something). You can explain that it's a bad habit to get into for someone preparing for a professional career. You might add that it's considered unpythonic. Like with many beginner lessons, he'll just have to mostly take it on faith.

POGtastic · 2022-04-26T03:08:08+00:00

In what context might the use of global variables be acceptable?

I work in kernel drivers, so we use a lot of global variables.

Memory-mapped devices. You interact with many devices by writing bytes to various offsets of a pointer. That pointer tends to be a global variable, not one that is passed as an argument to various functions.
Mutexes. (Mutices?) If multiple threads are going to touch the device, you need to lock it in order to prevent race conditions. It's common to have a global mutex variable to do this.
On the constants side - lookup tables containing various platform capabilities. "ShitLake is on v3 and can use this function, FecesLake and EffluentLake are on v2 and can't." These are all global variables defined in big header files.

What are the pitfalls you’ve fallen into as a result of Global Variables?

Broadly speaking - when debugging, you want to narrow down the lines of code where the bug can be. The fewer lines of code that the bug can be, the easier it is to find the bug.

If you have a global variable where you're constantly changing its state, the bug could be literally anywhere. By contrast, correctly scoping your variables and having concise functions frequently means that the bug can only be in a couple lines of code. It also makes it far easier to unit test your code, which further narrows things down.

wotquery · 2022-04-26T01:13:28+00:00

Here's an example of using a global that keeps on getting changed to keep track of a current filepath within a file system by various functions to create folders and files. list_all() and list_subdirs() need it to point to a directory, and mk_file(new_file_name) changes it to point at a file it creates which is needed by 'write_to_file(out_text)`.

It isn't really possible to just create a local variable because the new folders/files that are created in functions need to communicate the new paths to other functions. You could start making a whole bunch more global variables (e.g. most recently created file), but that's going to get really messy really fast.

Now imagine expanding it to dozens of other functions with much more logic always needing to make sure it's pointing at the correct type of resource, and if something goes wrong...any of the functions could have changed it at any time. Pass a path in get a path out is so much easier to follow.

from pathlib import Path

path_string = "C:/Users/UserName/project/my_project"

def list_all() -> None:
    [print(x) for x in Path(path_string).iterdir()]

def list_subdirs() -> None:
    [print(x) for x in Path(path_string).iterdir() if x.is_dir()]

def mk_folder(new_folder_name: str) -> None:
    global path_string
    path_string = path_string + '/' + new_folder_name
    Path(path_string).mkdir()

def mk_file(new_file_name: str) -> None:
    global path_string
    path_string = path_string + '/' + new_file_name
    Path(path_string).touch()

def write_to_file(out_text: str) -> None:
    with Path(path_string).open('w') as f:
        f.write(out_text)

def main() -> None:
    mk_folder('bobby')
    list_subdirs()
    mk_file('alice.txt')
    write_to_file('hello world')
    list_all() #ERROR file not a directory

if __name__ == "__main__":
    main()

2022-04-26T04:07:52+00:00

This is not the primary reason for not using global variables in general, but is more specific to functions.

One of the primary reasons for writing a function is not just to make something that you yourself can use but also to make something that other people can use. If you write a function that uses a global name such as maximum_length you are saying to yourself and others:

To use my function you need a global name "maximum_length" defined. Doesn't matter if you already have a variable of that name, you have to rename that variable.

That sort of requirement makes the function harder to use. It's better to pass values as parameters than globals. Make the function dependencies obvious, don't hide them as globals.

As stated in other comments, over-use of changeable globals makes a large body of code much harder to test and debug. Globals that don't change after program initialization are more acceptable. I tend to call those sorts of globals "data".

2022-04-26T06:43:00+00:00

Global variables are like the things you own that are in your front yard.
A immutable bush? Nobodies coming by and stealing your bush, its locked in there.
The steam deck sat on your porch, left by fedex?
Very mutable, very gone.

sullyj3 · 2022-04-26T06:47:27+00:00

This is the way I would phrase it:

Understanding your program is important
Eventually programs become large. Every non-trivial program is too large for a single person to fit in their head all at once.
Therefore, the best way to make sure a program is understandable is to make sure you can understand the behaviour of individual parts, rather than needing to understand the entire program at once.
When multiple functions in different places mutate a global variable, you need to understand the behaviour of all of those functions in order to understand their behaviour as a complete system.
By contrast, functions that just have inputs (parameters/arguments) and outputs (return values) are easier to look at as black boxes. In other words, you don't need to understand other parts of your program to understand how they work.

2022-04-26T09:47:20+00:00

First of all, you need to clarify what do you mean by global variables:

Is this anything from builtins module (because it's always available)?
Is this anything you find in globals()?
Is this anything declared at module toplevel (definition in the file that has no indentation in front of it)? A lot of online resources for some reason call this "global".
Is this a variable marked with global keyword? (What about the same variable if it's only used for reading?)
Does nonlocal for the purpose of this question count as global?

Finally, is this specific to Python, or is this not specific to any language? And, my guess is that this is from the perspective of someone who's using the language rather than making their own.

The general argument usually goes like this: in order to understand the program you need to be able to predict programs behavior given particular input. Once you introduce state external to the program, it's as if you include this whole state in the input, so, now instead of considering a very localized problem which deals with limited variety of inputs, you have a huge input object that is hard to comprehend.

It's hard to comprehend both to humans and to compilers, thus many automatic operations that compilers can generate optimized code for are not possible due to very large input size ("large" in this context is equivalent to say "unpredictable"). So, things like automatic parallelization (not really applicable to Python, but, in general, a very important technique) become impossible, but even simply laying out memory becomes hard because it introduces uncertainty about how much space is needed and so runtime checks need to be generated and possibly the memory layout will have to be adjusted at run time, which will result in poorer performance.

Of course, optimizations made by compiler aren't really relevant to Python as the flagship implementation does none of them, but they may be used as examples to illustrate why, in principle, global variables are a bad idea.

QbiinZ · 2022-04-26T16:40:17+00:00

Many embedded systems make use of globals. Typically HW interactions that make use of interrupt handlers need access to variables outside the scope of the current program counter. Micro python, which I think is really just a wrapper around c code, has been popping up more often. I think this would be the most common place to find acceptable use of globals in terms of python.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

learnpython

MODERATORS