Tach!
Finde ich nicht. Den Array-Zugriff
$_POST['tagesPreis']
zu wiederholen ist langatmig und fehleranfällig. Wenn sich der Array-Schlüssel mal ändern sollte, oder wenn man den Code später über den Schlüssel verallgmeinern möchte, dann müssen sämtliche Zugriffe geändert werden.Man kann da auch mit YAGNI argumentieren.
Kann man, meine Erfahrung ist allerdings, dass es sich lohnt in vorrauschauender Weise Abkürzungen im Quelltext zu platzieren. Man kann damit auch Mal daneben liegen, aber wo wäre dann dann der Nachteil gegenüber der repitiven Variante?
Wenn das Programm umfangreicher wird, wird man sicherlich irgendwann nicht mehr die Eingabedaten direkt verarbeiten, sondern sie aus diesen in Model-Objekte übertragen, so dass die eigentliche Geschäftslogik mit diesem Model arbeitet und von den Gegebenheiten auf dem Übertragungsweg nichts wissen muss. Auch das ist mehr oder weniger nur eine 1:1-Kopie, aber hier lässt sie sich gut begründen. Die Geschäftslogik wird nicht immer nur mit Eingabedaten arbeiten müssen, sondern auch mit Daten aus anderen Quellen, und dafür wird man die Daten quellenunabhängig vorliegen haben wollen.
Anders sieht es jedoch bei vielen Wald- und Wiesen-Scripten aus. Da spielt sich der Request innerhalb weniger Codezeilen ab. Oftmals verwendet man den Wert nur einmal, und das Umkopieren bringt nur Mehraufwand rein. Der Nutzen ist hierbei reichlich beschränkt.
Ob Vorteil oder Nachteil ergibt sich immer aus der Aufgabenstellung, und deswegen mag ich keine Pauschalaussagen, die eine bestimmte Methode als generell vorteilhafter als eine andere darstellt.
Trotzdem halte ich es für besser Array- und Objekt-Zugriffe nicht zu wiederholen. Es ist sicher auch ein Stück weit persönliche Abwägungssache, doch je länger der Zugriffspfad wird, desto eher wird man wohl dazu tendieren eine Variable als Abkürzung verwenden. Ich denke niemand würde bspw.
$foo->bar['baz']->lorem->ipsum['dolor']['sit']->amet()
gerne häufig wiederholen müssen. Und dann hängt es natürlich auch davon ab, wie oft man die Zeile schreiben müsste. Ich halte es eben lieber straff.
Die bessere Vorgehensweise in einem solchen Fall ist vermutlich nicht die Einführung einer Variable, sondern eher die Umstrukturierung von Daten und Verarbeitung, dass sich solche Monster erst gar nicht ergeben. Auch das muss man konkret für den Anwendungsfall entscheiden.
Das passiert bei falsch geschriebenen (und damit nicht existenten) Variablen ebenso. In beiden Fällen gibt es nur eine Notice-Meldung. Und diese sind unterdrückt, wenn man sie nicht explizit freikonfiguriert.
Das stimmt, bei Variablen können einem allerdings Code-Quality-Werkzeuge und IDEs weiter entgegenkommen, weil Variablenbezeichner von statischer Code-Analyse erfasst werden können.
PhpStorm beispielsweise kann auch bei Array-Keys eine solche Unterstützung bieten. Allerdings ist diese Hilfe bei PHP in beiden Fällen eingeschränkt, weil sich bestimmte Dinge erst zur Laufzeit ergeben und statisch analysiert aufgrind des Prinzips nicht erkannt werden können.
"Das "beste" aus dieser Situation" zu machen, ist schlicht die Rückgabe von null.
„I call it my billion-dollar mistake. It was the invention of the null reference in 1965.“ – Tony Hoare
Was du vermutlich meinst, ist das Weglassen der Anführungszeichen. Denn dann wird gutmütigerweise angenommen, man meine gar keine Konstante, wenn eine solche nicht existiert, sondern einen String.
Darauf wollte ich eigentlich nicht hinaus.
Dann verstehe ich nicht, was das Beste sein soll. Die Rückgabe von null, wenn man auf etwas nicht vorhandenes zugreift, ist für mich eher eine Notlösung. Schon eher in die Nähe des Besten käme, wenn PHP mitzudenken versucht, und das ausführt, was der Nutzer eigentlich will. Auch wenn solche Magie in manchen Fällen ungewünscht ist.
dedlfix.