nicht angemeldet
Hi!
Die Deklaration von $vs ist nie weit entfernt, sodass ich sofort den Bezug dazu habe. schneller als wenn ich schreibe $ResultatDerDBAbfrageWoIchInDerTabelleUsersNachDemMitDerEntsprechendenIdGesuchtHabe
$userData oder etwas ähnlich ist sicher weder übertrieben noch nichtssagend.
Um zu ausführliches möchte ich mich drücken, um sinnvolles nicht. Ich stosse oft auf fremden Code, bei dem ich erst drei viertel der Kommentare löschen muss damit ich mir einen Überblick verschaffen kann.
Und zwar genau solche Kommentare:
Der Rückgabewert von Page() und liveLog::$id sind garantiert ganze Zahlen,
deswegen ist keine Maskierung erforderlich
D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");
>
> Jetzt mal ehrlich, in diesem Fall musst du doch hier annehmen dass Page() eine "page\_id" also eine Zahl zurück gibt.
Ich persönlich treffe keine Annahmen, nur weil etwas so sein müsste, dass es funktioniert. An dieser Stelle kann ich höchstens hoffen. PHP ist keine typsichere Sprache, als Rückgabewert kann kein bestimmter Typ erzwungen werden. Für C# hingegen könnte man annehmen, dass das passt, besonders wenn man mit einer IDE à la Visual Studio unterwegs ist, die beim Positionieren des Mauszeigers auf Page() dessen Rückgabetyp (beziehungsweise die gesamte Signatur) anzeigt. Aber auch das wäre noch nicht 100% sicher, denn C# nimmt beim Verknüpfen von String und Integer stillschweigend eine Konvertierung vor. Wenn also eines Tages Page() einen String liefern würde, geht das genauso geräuschlos durch den Compiler wie der Integer.
Wenn du zumindest eine gewisse Beruhigung des leidgeprüften Programmiererauges erreichen willst, empfehle ich dir PHPDoc-Kommentare zu verwenden, denn die werden von den PHP-IDEs üblicherweise als kontextsensitive Hilfe beim Überfahren mit dem Mauszeiger angezeigt.
> Und wenn du Zweifel hast schaust du dir die Funktion Page() genauer an, dann weisst du es auch gleich für die Zukunft.
Nachschauen ist eine Möglichkeit, aber eine zeitaufwendige. Und in die Zukunft kann ich leider nicht sehen, weswegen ich mich sehr schwer tue, einmal gelernte Gegebenheiten als in der Zukunft unveränderlich zu betrachten.
> Vergleiche:
> -------------------------------------------------------
> ~~~php
$stmt = D()->prepare("UPDATE log SET page_id=:page_id WHERE id = :id ");
> $stmt->bindParam(':page_id', Page() );
> $stmt->bindParam(':id', $liveLog::$id );
> $stmt->execute();
vs
D()->query("UPDATE log SET page_id = '".Page()."' WHERE id = '".liveLog::$id."'");
Betrachte von PDOStatement->execute die Beispiele #2 und #3. Das sollte doch sowohl flexibel für beliebige Parameteranzahlen als auch komfortabel sein - und garantiert sicher obendrein. (Das ist ja der Vorteil von PDO gegenüber mysqli, dass du nicht zwingend extra binden musst, sondern es eine kombinierte Lösung mit PDOStatement->execute() gibt.)
Gut man könnte die prepared statments in einer Funktion kapseln damit es irgendwie so aussieht:
D()->myPreparedQuery("UPDATE log SET page_id=? WHERE id = ? ", Page(), $livelog::$id);
Dann würde ich aber keine separate Methode erstellen, sondern in query() ein Array als optionalen Parameter aufnehmen (Defaultwert: null). Dieses Array (oder das null) kannst du dann dem execute() übergeben und hast damit Querys mit und ohne Parameter erschlagen. Zudem ist es dir freigestellt, ob du positionierte oder benannte Platzhalter verwenden willst. Beides kannst du über das eine Array erledigen.
Das wäre eventuell noch sinnvoll, auch um andere Entwickler zu beruhigen :)
Hat die Nachteile, dass es nicht mehr ganz so gut lesbar ist und dass man einen Zwischenschritt einbaut, was die Komplexität des Codes erhöht.
Nun, das optionale Array erhöht den bestehenden Code nur ganz geringfügig, bringt dich aber einen enormen Schritt bei der Funktionalität und Sicherheit nach vorn. (Ich weiß nicht, ob du jetzt schon P.S. verwendest oder erst noch query() gegen prepare() und execute() tauschen musst, aber dieser Aufwand ist auch recht gering.)
Lo!