Notification Free PHP Coding
This is a reply to http://100days.de/serendipity/archives/50-Notification-Free-PHP-Coding.html. Gaylord Aulke’s opinions are normally quite valuable. There are a couple of arguments (just read the comments) in both directions and to be fair, Gaylord also said, that his opinion is different for frameworks and libraries.
Even though I tend look into PHP notifications (some code produces so much of them, that you can only ignore them), I wasn’t really sure what my final position on Notification Free PHP Coding is and I was not too strict about it.
That changed today.
While demonstrating my reporting frontent for PHPUnit to the customer this month, I had to find out that it’s JUnit/XML logger sometimes produces broken XML files: You can get a “PCDATA invalid Char” exception when loading it with DOMDocument::load(). Sebastian Bergmann encouraged me to send a pull request on github, which is nice. Except that I never contributed to PHPUnit before. Nor did I actively use github. Like Lars Jankowfsky I tend to stay with SVN, when possible (that’s probably worth another blog post).
Anyways: It was easy to fix the bug (actually, it turned out to be more complex) and after reading a couple of git manuals, I found out how to commit, push and send a pull request. The only thing I didn’t notice is that I used the constant ENT_QUOT (undefined) instead of ENT_QUOTES (defined) as an argument to htmlspecialchars() for some reason – this is why I recommend to focus on each line of code to other people…
htmlspecialchars(self::convertToUtf8($string), ENT_QUOT, ‘UTF-8′)
Not a big thing, if I would have seen the PHP notice!
Notice: Use of undefined constant ENT_QUOT – assumed ‘ENT_QUOT’
It was not possible to see it, not because I did not look at the error messages or the test results, but because the default config for PHP on Ubuntu is error_reporting = E_ALL & ~E_NOTICE. To use an undefined constant is just plain wrong and leads to an undefined state of the software – it must be noticed. Also, whenever there are too much notices, you won’t be able to spot it. Therefore the only way to avoid it is to produce notification free code. I don’t want something embarrassing like this ever happen to me again.
Lesson learned.
I didn’t mean that notifications cannot be useful. When in search of an error, turn them on and you see some hints. Some might help, some are false-positives. This is why they are notifications, not warnings or errors.
BTW: The fact that unknown constants don’t trigger any warning or error results from another oddness of PHP: System.out.print(test); // works in php as Ivo has blogged long ago
I agree that logfiles should be clean (also from debug output) when in production.
But on the other side this needs to be put in relation with the effort. Constructs like this are too much:
$email = (key_exists(‘email’, $values)) ? $values['email'] : null;
If you just use $values['email'], it might be null. This is 1:1 replicated by this line with the difference that it is hard to read and makes the code more complicated…
The best way to good and stable code is simplicity and good design. This means: prevent technical noise in the code to make it as simple as possible. Design the code in a way that it is easy to read and understand. And use the programming language as it was designed…
Comment by Gaylord — August 24, 2010 @ 07:59
Aha
So I prefer SVN over GIT ? Interesting
Actually my answer would be “it depends”. For real distributed development which usually takes place in OSS GIT does make a lot of sense. For “standard” code versioning – yes, then I prefer SVN
Comment by Lars Jankowfsky — August 30, 2010 @ 17:12