> statt $_GLOBALS kann man auch das global Statement verwenden. * [PHP-Handbuch zum statement (was es ist)/„Schlüsselwort“(wie es dort heißt) „global“)](https://www.php.net/manual/de/language.variables.scope.php#language.variables.scope.global) Ja. Auch der Mist geht. Das die Variable `$GLOBALS` heißt ist auch so ein *„Hirnfurz“*: [Superglobale Variablen](https://www.php.net/manual/de/language.variables.superglobals.php) sind `$_SERVER`, `$_GET`, `$_POST`, `$_FILES`, `$_COOKIE`, `$_SESSION`, `$_REQUEST`, `$_ENV` und dann (**„Peng!“**) `$GLOBALS`! Wenn ich ganz ehrlich bin, dann bin ich *„nicht besonders hell begeistert“*, wenn man in Programmiersprachen ein- und das selbe auf gefühlte 16.389 Weisen machen kann. Diese ganzen Aliase und Alternativen (mit teilweise kruden Schreibweisen) muss man zwar nicht selbst benutzen, aber wahrscheinlich lesen. * Und bei manchen dann auch noch um die im Detail liegenden Abweichungen wissen… Und für die zugehörigen Parser, Linter, Interpreter oder Kompiler gilt das letztendlich auch. Mir kann keiner erzählen, dass eine solche Alternativenwulst die Ausführung von Skripten schneller macht und auch nur irgendwas vereinfacht. Ich denke, da werden einfach Designfehler der Programmiersprache (*„Hirnfürze“*) konserviert. **Zur Berechnung im Titel:** *„Nur“* 100 Items, welche die Kompilierungs- oder Ausführungszeit eines Programmes jeweils um *„unbeachtliche“* 0,5% erhöhen, machen es im schlimmsten Fall so langsam, dass es die 1,646-fache Zeit braucht…

> statt $_GLOBALS kann man auch das global Statement verwenden. * [PHP-Handbuch zum statement (was es ist)/„Schlüsselwort“(wie es dort heißt) „global“)](https://www.php.net/manual/de/language.variables.scope.php#language.variables.scope.global) Ja. Auch der Mist geht. Das die Variable `$GLOBALS` heißt ist auch so ein Hirnfoo: [Superglobale Variablen](https://www.php.net/manual/de/language.variables.superglobals.php) sind `$_SERVER`, `$_GET`, `$_POST`, `$_FILES`, `$_COOKIE`, `$_SESSION`, `$_REQUEST`, `$_ENV` und dann (**„Peng!“**) `$GLOBALS`! Wenn ich ganz ehrlich bin, dann bin ich *„nicht besonders hell begeistert“*, wenn man in Programmiersprachen ein- und das selbe auf gefühlte 16.389 Weisen machen kann. Diese ganzen Aliase und Alternativen (mit teilweise kruden Schreibweisen) muss man zwar nicht selbst benutzen, aber wahrscheinlich lesen. * Und bei manchen dann auch noch um die im Detail liegenden Abweichungen wissen… Und für die zugehörigen Parser, Linter, Interpreter oder Kompiler gilt das letztendlich auch. Mir kann keiner erzählen, dass eine solche Alternativenwulst die Ausführung von Skripten schneller macht und auch nur irgendwas vereinfacht. Ich denke, da werden einfach Designfehler konserviert. **Zur Berechnung im Titel:** *„Nur“* 100 Items, welche die Kompilierungs- oder Ausführungszeit eines Programmes jeweils um *„unbeachtliche“* 0,5% erhöhen, machen es im schlimmsten Fall so langsam, dass es die 1,646-fache Zeit braucht…

> statt $_GLOBALS kann man auch das global Statement verwenden. Ja. Auch das geht. Das die Variable `$GLOBALS` heisst ist auch so ein Hirnfoo: [Superglobale Variablen](https://www.php.net/manual/de/language.variables.superglobals.php) sind `$_SERVER`, `$_GET`, `$_POST`, `$_FILES`, `$_COOKIE`, `$_SESSION`, `$_REQUEST`, `$_ENV` und dann (**„Peng!“**) `$GLOBALS`! Wenn ich ganz ehrlich bin, dann bin ich *„nicht besonders hell begeistert“*, wenn man in Programmiersprachen ein- und das selbe auf gefühlte 16.389 Weisen machen kann. Diese ganzen Aliase und Alternativen (mit teilweise kruden Schreibweisen) muss man zwar nicht benutzen, aber womöglich lesen. Und bei manchen dann auch noch um die im Detail liegenden Abweichungen wissen… Und für die zugehörigen Parser, Linter, Interpreter oder Kompiler gilt das letztendlich auch. Mir kann keiner erzählen, dass eine solche Alternativenwulst die Ausführung von Skripten schneller macht. **Zur Berechnung im Titel:** *„Nur“* 100 Items, welche die Kompilierungs- oder Ausführungszeit eines Programmes jeweils um *„unbeachtliche“* 0,5% erhöhen, machen es im schlimmsten Fall so langsam, dass es die 1,646-fache Zeit braucht…

> statt $_GLOBALS kann man auch das global Statement verwenden. Ja. Auch das geht. Das die Variable `$GLOBALS` heisst ist auch so ein Hirnfoo: [Superglobale Variablen](https://www.php.net/manual/de/language.variables.superglobals.php) sind `$_SERVER`, `$_GET`, `$_POST`, `$_FILES`, `$_COOKIE`, `$_SESSION`, `$_REQUEST`, `$_ENV` und dann (**„Peng!“**) `$GLOBALS`! Wenn ich ganz ehrlich bin, dann bin ich *„nicht besonders hell begeistert“*, wenn man in Programmiersprachen ein- und das selbe auf gefühlte 16.389 Weisen machen kann. Diese ganzen Aliase und Alternativen (mit teilweise kruden) Schreibweisen muss man zwar nicht benutzen, aber womöglich lesen. Und bei manchen dann auch noch um die im Detail liegenden Abweichungen wissen… Und für die zugehörigen Parser, Linter, Interpreter oder Kompiler gilt das letztendlich auch. Mir kann keiner erzählen, dass eine solche Alternativenwulst die Ausführung von Skripten schneller macht. **Zur Berechnung im Titel:** *„Nur“* 100 Items, welche die Kompilierungs- oder Ausführungszeit eines Programmes jeweils um *„unbeachtliche“* 0,5% erhöhen, machen es im schlimmsten Fall so langsam, dass es die 1,646-fache Zeit braucht…

> statt $_GLOBALS kann man auch das global Statement verwenden. Ja. Auch das geht. Das die Variable `$GLOBALS` heisst ist auch so ein Hirnfoo: [Superglobale Variablen](https://www.php.net/manual/de/language.variables.superglobals.php) sind `$_SERVER`, `$_GET`, `$_POST`, `$_FILES`, `$_COOKIE`, `$_SESSION`, `$_REQUEST`, `$_ENV` und dann (**„Peng!“**) `$GLOBALS`! Wenn ich ganz ehrlich bin, dann bin ich *„nicht besonders hell begeistert“*, wenn man in Programmiersprachen ein- und das selbe auf gefühlte 16.389 Weisen machen kann. Diese ganzen Aliase und Alternativen (mit teilweise kruden) Schreibweisen muss man zwar nicht benutzen, aber womöglich lesen. Und bei manchen dann auch noch um die im Detail liegenden Abweichungen wissen… Und für die zugehörigen Parser, Linter, Interpreter oder Kompiler gilt das letztendlich auch. Mir kann keiner erzählen, dass eine solche Alternativenwulst die Ausführung von Skripten schneller macht. **Zur Formel im Titel:** Nur 100 Items, welche die Kompilierungs- oder Ausführungszeit eines Programmes jeweils um *„unbeachtliche“* 0,5% erhöhen ,machen es im schlimmsten Fall so langsam, dass es die 1,646-fache Zeit braucht...