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 sich selbst wiederholenden Variante?
Speichert man dagegen das Ergebnis direkt in einer Variablen, gibt es nur einen Punkt mit Änderungsbedarf.
Wenn man refakturiert, muss man zwangsläufig aufmerksam sein, auch wenn man sich das Leben (angeblich) vereinfacht hat. Wer sagt denn, dass sich nur der Feldbezeichner ändert und nicht stattdessen der Variablenname, oder gar beides? Ich halte das für kein allgemeingültiges Argument.
Zumindest ist es kein gutes Argument. 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 folge da lieber dem DRY-Prinzip.
Außerdem sind PHPs assoziative Arrayzugriffe wegen des String-typisierten Schlüssels schon für sich anfällig für Tippfehler. Und das sind wirklich bösartige Fehler, weil PHP dann nicht sofort mit einem lauten Krach darauf aufmerksam macht, sondern versucht das "Beste" aus der Situation zu machen, so kann der Fehler lange unbemerkt bleiben und durch die Anwendung propagieren. Gut gemeint ist eben nicht gut gemacht.
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.
"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.
Außerdem sollte man tunlichst vermeiden PHPs
$_POST
-Array selber zu beschreiben. Der Schein trügt, dass es nur einen gerinfügigen Unterschied mache, ob ein$_POST
-Element den leeren String enthält oder gar nicht gesetzt ist. Das zeigt dieser Fall sogar besonders deutlich: Array-Element nicht gesetzt bedeutet, dass die Checkbox nicht ausgewählt wurde. Array-Element gesetzt bedeutet, dass die Checkbox ausgewählt wurde, und zwar unabhängig vom Wert, der drin steht. Gegenteiliger könnte die Semantik kaum sein.Dem kann man mit !empty() statt isset() abhelfen.
Mit empty() kannst du auf unterschiedliche falsy-Werte gleichzeitig testen, aber du kannst dadurch nicht die Semantik zurückgewinnen, dass eine Checkbox ausgewählt wurde, nachdem du das $_POST-Array selber beschrieben hast.