Avoid using the global keyword unnecessarily as it leads to code that is harder to test, debug, and maintain; instead, use function parameters and return values to pass data explicitly. 2. Replace global variables with pure functions that depend only on their inputs and produce outputs without side effects, improving predictability and testability. 3. Use classes to encapsulate and manage shared state when multiple functions need to modify related data, enabling reusability and avoiding global namespace pollution. 4. Leverage closures for maintaining private, controlled state across function calls without relying on global or class-based state. 5. Reserve global for rare cases like simple scripts or temporary module-level patches, but always consider whether the same can be achieved through parameter passing, return values, or encapsulation. 6. Treat global like a spare tire—useful in emergencies but unsuitable for regular use, as avoiding it promotes cleaner, more modular, and maintainable code design.

You don’t need the global keyword as often as you might think—and overusing it is a sign your code could be more readable, testable, and maintainable. While global has its place in Python, reaching for it too quickly often leads to tangled, hard-to-follow logic. Here’s how to write cleaner code by avoiding unnecessary global state.

Why global Is a Code Smell

The global keyword lets you modify a variable defined in the global scope from within a function. But when you use it, you’re tightly coupling that function to external state. That makes your code:

• Harder to test (you need to manage global state between tests)
• Difficult to reason about (who changed what, and when?)
• Prone to bugs in concurrent or recursive contexts
• Less reusable (the function won’t work without specific global variables)

Instead of modifying global variables, aim for pure functions—functions that depend only on their inputs and return a value without side effects.

Replace Global Variables with Function Parameters and Returns

One of the simplest and most effective strategies is to pass data in and return results explicitly.

Instead of this:

counter = 0

def increment():
    global counter
    counter  = 1

Do this:

def increment(counter):
    return counter   1

# Usage
counter = 0
counter = increment(counter)

Now the function is self-contained, predictable, and easy to test:

assert increment(5) == 6

If you’re managing more complex state, consider returning multiple values or using a dictionary or dataclass:

def process_user(data, score):
    return {**data, 'processed': True}, score   10

Use Classes to Manage Shared State

When you genuinely need to maintain and modify state across multiple function calls, a class is usually a better fit than global variables.

Instead of:

user_name = ""
login_status = False

def login(name):
    global user_name, login_status
    user_name = name
    login_status = True

Use a class:

class UserSession:
    def __init__(self):
        self.user_name = ""
        self.login_status = False

    def login(self, name):
        self.user_name = name
        self.login_status = True

# Usage
session = UserSession()
session.login("Alice")

This approach encapsulates state, avoids global pollution, and makes it easy to have multiple independent instances.

Leverage Closures for Controlled State Access

Sometimes you want to hide state but still avoid globals. Closures let you encapsulate data within a nested function scope.

def create_counter():
    count = 0
    def increment():
        nonlocal count
        count  = 1
        return count
    return increment

# Usage
counter = create_counter()
print(counter())  # 1
print(counter())  # 2

Here, count is not global, not part of a class, but still maintains state across calls—without global. It’s private, reusable, and thread-safe (as long as you don’t share the closure).

When Is global Acceptable?

There are rare cases where global makes sense:

• Patching module-level constants during testing (though monkeypatching tools are better)
• Simple scripts or prototypes where clarity isn’t critical
• Singletons or configuration flags (but consider using a config object instead)

Even then, ask: Can I pass it in? Can I return it? Can I encapsulate it?

Bottom Line

Avoiding global pushes you toward better design: smaller functions, clearer dependencies, and more modular code. You’ll write fewer bugs and make your code easier to test and reuse.

Refactor global dependencies into parameters, return values, classes, or closures. The extra few lines of code are worth the long-term clarity.

Basically, treat global like a spare tire—useful in a pinch, but not for everyday driving.

The above is the detailed content of The Case Against the `global` Keyword: Strategies for Cleaner Code. For more information, please follow other related articles on the PHP Chinese website!