$GLOBALS is not inherently bad; it is a tool whose value depends on its use. It is an associative array providing access to all global variables, allowing functions to read global variables without the global keyword. Its negative reputation stems from encouraging global state, obscuring dependencies, promoting tight coupling, and making changes harder to track—issues tied to misuse, not the tool itself. However, $GLOBALS can still be useful in specific scenarios: 1. Legacy code maintenance where refactoring is impractical; 2. Simple scripts using $GLOBALS for basic configuration; 3. Advanced debugging or hook systems, such as in WordPress; 4. Rare cases like runtime patching or testing with temporary overrides. If used, best practices include documenting usage clearly, avoiding unnecessary modifications, not relying on it for core logic in new applications, and isolating its use to bootstrapping or configuration layers. In modern PHP, dependency injection and explicit parameter passing are preferred for better testability and maintainability. Therefore, while $GLOBALS remains functional and has niche applications, it should generally be avoided in favor of more predictable patterns—understand it, but choose not to use it without a justified reason.

$GLOBALS is one of PHP’s superglobals—global variables that are available in all scopes throughout a script. Over the years, it has developed a reputation as something to avoid, often labeled as a "historical relic" or a sign of poor coding practices. But is it truly obsolete, or is it simply misunderstood?

The short answer: $GLOBALS is not inherently bad—it’s a tool, and like any tool, its value depends on how it’s used.

Let’s break down what $GLOBALS is, why it gets a bad rap, and when it might still be useful.

What Is $GLOBALS?

$GLOBALS is an associative array that contains references to all variables defined in the global scope of a PHP script. For example:

$foo = 'hello';
function example() {
    echo $GLOBALS['foo']; // Outputs: hello
}

Unlike other superglobals like $_GET or $_POST, $GLOBALS gives you direct access to user-defined global variables from within functions, without needing to use the global keyword.

This behavior makes it powerful—but also dangerous if misused.

Why $GLOBALS Gets a Bad Reputation

Several reasons contribute to its negative image:

• Encourages global state: Relying on $GLOBALS can lead to code that depends on global variables, making functions harder to test, debug, and maintain.
• Obscures dependencies: When a function accesses $GLOBALS['something'], it’s not immediately clear what external state it depends on.
• Promotes tight coupling: Code that pulls variables from the global scope becomes tightly coupled to that scope, reducing reusability.
• Harder to track changes: Since any part of the code can modify a global variable, tracking down bugs becomes more difficult.

These issues are real and serious—especially in large applications or team environments where predictability and maintainability matter.

But blaming $GLOBALS itself is like blaming a knife for a bad cut. The problem isn’t the tool—it’s how it’s wielded.

When $GLOBALS Might Still Be Useful

While modern PHP development favors dependency injection, service containers, and explicit parameter passing, there are niche cases where $GLOBALS can be practical:

1. Legacy Code Maintenance

In older PHP applications (especially pre-OOP or procedural systems), $GLOBALS is often already in use. Refactoring everything at once may not be feasible. In such cases, understanding and safely working with $GLOBALS is necessary.

2. Configuration or Constants in Simple Scripts

In small utility scripts or shared hosting environments where simplicity is key, some developers use $GLOBALS to manage configuration:

$GLOBALS['config'] = [
    'db_host' => 'localhost',
    'debug'   => true
];

While constants or config files are better, this pattern isn’t catastrophic in tiny projects.

3. Advanced Debugging or Hook Systems

Some frameworks or debugging tools use $GLOBALS to inject data for inspection or to implement hook mechanisms. For example, WordPress (though controversially) uses global state extensively, and plugins sometimes interact with it.

4. Runtime Patching or Testing (Rare)

In very specific testing scenarios—like monkey-patching global variables during unit tests—$GLOBALS can be used to temporarily override values. However, this should be done cautiously and with cleanup.

Best Practices (If You Must Use It)

If you find yourself needing to use $GLOBALS, follow these guidelines:

• Document usage clearly: Make it obvious why a global variable is being accessed.
• Avoid modifying globals unnecessarily: Treat them as read-only when possible.
• Never use $GLOBALS for core logic flow in new applications: Prefer dependency injection.
• Isolate usage: Keep global access in bootstrapping or configuration layers, not deep in business logic.

Conclusion

$GLOBALS isn’t a “relic” in the sense of being broken or deprecated—it still works and has valid, albeit narrow, use cases. But in modern PHP development, it’s generally better to avoid it in favor of more predictable, testable patterns.

Calling it a relic oversimplifies things. It’s more accurate to say it’s a low-level feature that’s easy to abuse and hard to justify in well-structured applications.

So no, $GLOBALS isn’t evil. But unless you have a clear, justified reason, you’re probably better off without it.

Basically: know it, understand it, then choose not to use it.

The above is the detailed content of $GLOBALS: A Historical Relic or a Misunderstood Tool?. For more information, please follow other related articles on the PHP Chinese website!