Refactoring macht mir viel Spaß. Das hat viele Gründe: man sieht wie andere Programmierer bestimmte Probleme gelöst haben, man sieht wie Sachen gemacht oder besser nicht gemacht werden sollen, man arbeitet mit altem Code. Dabei sind mir schon einige kuriose Codefragmente aufgefallen wo ich schmunzeln musste. Aktuell stehe ich vor einem Codefragment wo ich mich erst fragen muss – ob so was überhaupt ge-parsed werden kann. Hier das Codefragment in einer vereinfachten Art und Weise:
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', true);
//try
{
$conan = 1;
$power = 1;
print ($conan + $power).PHP_EOL;
}
//catch (Exception $e)
{
// do nothing ...
}
In das oben aufgeführte Beispiel, hat man nur das „try“ und „catch“ auskommentiert. Häää?! Ich verstehe leider nicht, was hier die Absicht des Programmierers war – aber gut. Habe den Script mit „php -l“ nach PHP Einlesefehler geprüft. Ergebnis – alles OK!!! Habe das Script ausgeführt. Ergebnis – wieder alles OK!!! Wie ist es möglich, dass solch eine Syntax funktioniert? Woher kommt das? Ist das eine Anomalie oder Absicht im PHP?
Funktioniert das noch, wenn man die Kommentare weg macht? Also { … } { … }
Das ist eher Absicht als Anomalie. Man kann Statements mittels geschweifter Klammern zu Blöcken zusammenfassen.
Das ist einfach ein Block. In vielen Sprachen bedeutet das einen eigenen Scope, in PHP aber nicht. Wozu es überhaupt existiert in PHP, weiß ich nicht, aber es ist gültig und bedeutet schlussendlich nichts.
Das Auskommentieren von try und catch führt dazu, dass zunächst der try-Block ganz normal ausgeführt wird, allerdings ohne Fangen von Ausnahmen. Anschließend wird aber auch der catch-Block ausgeführt! Wenn dort etwas stünde, hätte man also ein fehlerhaftes Resultat.
Das ist eine normale Funktionalitaet.
Variablen, die innerhalb dieser Bloecke definiert werden, haben auch nur dort ihren Gueltigkeitsbereich (also wie innerhalb von Funktion oder anderen Bloecken auch)
geschweifte klammern sind in php abgrenzungen. das gibt es in der java-welt auch. damit werden code-blöcke definiert. diese können eine schleife, condition, klassendefinition oder funktion umschließen. aber halt auch quellcode in mehr oder weniger deutlicher herausstellen.
{} ist genau so möglich wie {echo „hallo welt, ich bin in zwei klammern versteckt“}
über sinn und unsinn möchte ich an dieser stelle nichts sagen :)
ps: auch leere statements wie
;
sind möglich!
Ein Kollege von mir mochte es große Scripte in riesige Dateien zu schreiben. Der hat die Blocksyntax genutzt um mittels des Codefoldings seiner IDE Übersicht über seine Zigtausendzeilendateien zu halten. Kein schöner Stil aber durchaus funktionierend…
@Stefan: Nein, das ist nicht so. Das ist übrigens auch z. B. bei Schleifen in PHP nicht der Fall. Darin gesetzte Variablen sind auch später weiter gültig.
@Christopher: ah ok. War mir noch aus Urzeiten so in Erinnerung, aber war wohl ein Falsch zugeordneter Gedaechtnisfetzen.
Viel lustiger finde ich dass folgendes problemlos geparsed wird:
$a = ‚blubb‘;
1234566789890;
„Einfach mal noch ein String die nichts macht^^“;
echo $a;
Würde lediglich „blubb“ ausgeben. Es wird auch keine Notice erzeugt.
Die geschweiften Klammern haben noch einen ganz anderen Zweck. Am Besten zeig ich das an einem Beispiel:
$wurst = „foo“;
class Bar
{
protected $bar = 1;
public function foo()
{
return $this->bar;
}
}
$bar = new Bar();
echo $bar->{$wurst}();
Ich glaube, neuere PHP Versionen können das auch ausführen ohne die geschweiften Klammern, bin mir da aber nicht sicher.
@Bob: Warum auch nicht? Das sind alles Ausdrücke. Rückgaben von Ausdrücken werden nicht automatisch ausgegeben – wäre ja auch noch schöner!
Zum Block: Bin ich früher auch mal drüber gestolpert. Ich hatte auch überlegt, das fürs Codefolding zu mißbrauchen. Aber irgend ein Problem gabs damit. Entweder eine PHP-Version, die das nicht unterstützte oder ein Editor/eine IDE, die damit nicht klar kam.
Super neuer Beitrag! Ich werde da noch mal genauer recherchieren!
@Dennis: Ja, PHP 5 kann das auf jedenfall auch ohne die geschweiften Klammern ausführen. Bin mir allerdings nicht ganz sicher, aber welcher Version das genau eingefügt wurde. Es funktioniert auf jedenfall mit PHP 5.2 und PHP 5.3:
@Gjero: Bei der Kommentarfunktion stimmt der Hinweis „*Codebeispiele können im PRE-Tag angegeben werden.“ nicht, wenn man das führende PHP-Tag angibt. Siehe meinen Kommentar zuvor.
@Daniel: Huh, das habe ich übersehen. Danke dir! Das sollte nun mit ein CODE Tag gehen.