Kategorien
E_STRICT ist günstiger
Mal wieder ein konfuser Titel, von dem nur ich weiß, was er zu bedeuten hat. Aber eigentlich ist es ganz einfach. Es geht um die Error-Level, die man so einstellen kann. Natürlich würde mir jeder zustimmen, wenn ich sagen würde, stellt es auf E_STRICT ein, damit euch auch die potentiellen Fehlerquellen angezeigt werden.
Wenn ich ehrlich bin, dann nerven mich viele NOTICES, die angezeigt werden, wenn man E_STRICT anzeigt und immer zu prüfen, ob ein Array auch existiert, wenn ich ihn auf leer prüfen will, geht mir auch auf den Sack. Man denkt ja auch, dass man diese Abfrage nicht braucht, denn wenn man nicht ganz so strikt prüft, dann geht’s ja auch.
Worauf ich hinaus will. Oft hat man das Gefühl, man muss mehr Code schreiben, damit man E_STRICT zufrieden stellt. Und meist bedeutet zusätzlicher auch, dass das System langsamer wird. Das ist aber ein Trugschluss – wie ich bei der PHP Conference gelernt habe. Auch wenn ich meinen Errorlevel so eingestellt habe, dass ich NOTICES nicht anzeigen lasse, dann werden diese „Fehler“ ja trotzdem geworfen. Aber eben nicht angezeigt. Das Finden und Ausgaben dieses Fehlers ist dann oft teurer, als die tatsächliche Prüfung im Source-Code, so dass die Notice gar nicht mehr angezeigt wird.
Joa soviel dazu. Leider habe ich im Laufe meines Lebens an so vielen Projekten gearbeitet, bei denen sich gar nicht die Frage stellt, ob man Notices angezeigt bekommt, denn sonst würde das System durchdrehen und so viel um sich werfen, dass man lieber in Deckung geht.
Hinzukommt, dass NOTICES die man ignoriert gerne auch mal Folgefehler und Seiteneffekte ausloesen. Denn PHP versucht ja in dem Fall of zu raten, was du meinst, liegt aber nicht immer richtig.
Ich hab E_STRICT immer an und kuemmere mich auch zeitnah um NOTICES. Das erzieht einen selbst und verbessert den Code.
array_key_exists() macht ja zB auch gleich visuell deutlicher, dass du prüfst.
Jow Notices können teuer sein, hatte ich vor einiger Zeit schon festgestellt:
http://www.robo47.net/blog/194-How-do-NOTICES-influence-php-scripts-performance
Ich denke jeden Code den man selbst schreibt sollte mit E_STRICT lauffähig sein, Ausnahmen kann man für legacy-apps und libs machen, gerade mit php 5.3 und manchen PEAR-Paketen gibt es ja die ein oder anderen fehler die kommen.
Ausnahmen kann man für fertigsysteme die man nicht von grund auf neu schreiben will machen, weil sie halt laufen oder einem die arbeit abnehmen.
Ich hab für jemand ein gallery 2 auf ner Kiste mit php 5.3 laufen, wenn ich da E_STRICT aktiviere und php die fehler mitloggen lasse, wächst die error-log jeden tag um ein paar GB, weil ein haufen statische zugriffe auf nicht statische methoden vorhanden sind und so kram, unschöner Code, aber nichts was ich jetzt einfach mal so eben ändern will 🙂
„Das Finden und Ausgaben dieses Fehlers ist dann oft teurer, als die tatsächliche Prüfung im Source-Code, so dass die Notice gar nicht mehr angezeigt wird.“
Wobei das ja nur im Fehlerfall passiert. Die Prüfung passiert aber jedenfalls. D.h. so lange die Variablen sauber gesetzt sind ist das ohne Prüfung schneller.
Nun sollte aber Korrektheit des Codes vor Mikro-Optimierung gehen.
Achja und was wirklich „langsam“ ist ist @ zum verstecken. Und wirklich die Hölle zum Fehler finden.
Danke für den Link robo47. Echt krass mit der Performance. Natürlich ist das ein idealisiertes Beispiel, zeigt aber doch welche Tücken es haben kann die Notices nicht zu berücksichtigen.
Ich gebe zu, noch bin ich auch ein „E_ALL ~ E_NOTICE“er 😉
Also wenn es geht versuche ich NOTICES zu aktivieren und diese Fehler auch zu entfernen. Weil in der Tat sind das oft echte kleine Fehler. Das System kann sie zwar meist kompensieren aber trotzdem hat man ungültige Daten.
Zum Beispiel wenn man bei SimpleXML ein & nicht sauber maskiert meckert es einen mit einer NOTICE an. Natürlich läuft das auch alles sauber durch. Und die meisten XML Parser fressen das auch. Nur es ist eben kein sauberes XML was man erzeugt hat.
Ebenso sind auch die Hinweise, dass man da auf Array-Felder zugreifen will die es nicht gibt sehr hilfreich. Weil so bekommt man evtl mit das man irgendwo einen kleinen Typo hatte. weil $array[‚myname‘] ist etwas anderes als $array[‚myName‘]. Im Zweifel verliert man so einige Daten.
Dummerweise funktioniert die STRICT Welt nur so lange schön, wie man nur eigenen Code hat. Sobald man fremde unsaubere Libraries einbindet an denen man oft nicht ändern kann oder darf, dann rauscht einem das Logfile zu, dass einem schlecht wird. =(
Mit Notices findet man auch deprecated Code, so dass man frühzeitig sieht, was nach dem nächsten major release von PHP evtl. gar nicht mehr funktioniert.
Tipp: statt array_key_exists() zur Prüfung zu verwenden sollte man isset($array[‚key‘) verwenden, da es schneller ist.
@Dennis Becker
Prinzipiell ja, muss man aber ziemlich aufpassen, es verhält sich nicht zwingend gleich, zB. wenn ein Wert NULL ist.
Oft lohnt es sich hier aber über DTOs anstelle von arrays nachzudenken, damit hat man dann nicht soviel Ärger.
Bei Fremdcode Einbindung muss man ja nicht gleich auf E_STRICT verzichten, man kann ja vor der Verzweigung den Level runtersetzen und danach wieder hochsetzen (aber ja nicht @silencen :)).
Im Zweifel hilft immer empty, das kann auch mit Arrays. Jedenfalls für den Anwendungsfall:
„immer zu prüfen, ob ein Array auch existiert, wenn ich ihn auf leer prüfen will“
Ich bin mittlerweile auch unter E_STRICT unterwegs. Bei der letzten Redaxo-Installation bin ich fast vom Stuhl gefallen…