Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
A global variable or object is in scope everywhere. That means it's possible to modify it from any part of your program. Imagine a mature program, made up of thousands of lines of code and dozens ...
Answer
#1: Initial revision
A global variable or object is in scope everywhere. That means it's possible to modify it from any part of your program. Imagine a mature program, made up of thousands of lines of code and dozens of files. A statement that does something with that global variable could be found anywhere in those. That means if you want to understand the impact of doing something with that variable, or you want to understand how its value will change. You will have to check every line of the program to look for references to the global variable. Sometimes global variables can get reused, because the global namespace is limited. So for example, maybe the variable is changed in 50 places. But for the particular usage of the variable that you're interested in, only 3 of those are relevant, and the others happen in a different context that does not apply to your particular usage. You can't easily tell which ones are relevant or not, so even when trying to understand a simple pattern, you will still have to deal with many complex code paths - worse, they'll be harder to understand because they don't tie into the thing you're thinking. Related - because global variable names are active across the program, you end up having to give them descriptive names, which are long and harder to come up with. Local objects are much more limited. For example, a local variable in a function is created after the function starts, is destroyed when it exits/returns, and can only be accessed from inside the function. That massively narrows down how much code you need to read to understand it. The namespace is limited, so you can give shorter, more generic names (that are still clear in context). It's a lot easier to build software when it is made up of self-contained *modules*. If you can treat each part of the program as a black box, with simple inputs and outputs and predictable behavior, it becomes easier to understand how the whole thing works. Global variables are effectively additional, poorly defined inputs/outputs that hampers this. It will also be harder to take one module and reuse it in another program, because now you must make sure the global variable is re-created in the new place as well. It's rare to encounter problems in software engineering that cannot be solved with local variables. They do exist, but they are rare. Often, people use globals not because they're needed, but because they're a sort of nuclear option to the scope problem. They're a way to avoid thinking about scope. It's like giving everyone the key to a room, instead of trying to figure out who actually needs that key. This shortcut saves a little effort in the short term, but leads to a lot of headache in the long term. This is why the advice exists to avoid global variables where possible.