Nothing to Fear

User Friendly
Laurence Liss
Laurence Liss

We have a joke at Zivtech that PHP typecasting bites someone at least once a week. Though to be fair, that someone is usually me. Others seem less affected, but it remains a problem. I find that as I become a better programmer, typecasting becomes more annoying. My problem seems partially related to my attempt to write better code, which I find humorous. I just want functions and APIs that return consistent, sane values. When functions return different kinds of values in different situations it makes programming difficult. If a function is supposed to return a text string, it should always return a text string. It shouldn't return FALSE sometimes and a string the rest of the time. If a function receives invalid data, it should throw an error and fail. If it finds no results it should return an empty string. Then as the programmer debugging this function, you only need to check properties related to strings and not those associated with arrays, booleans, or integers. By far the typecast issue that causes the most aggravation is the use of the number zero. Zero is an integer. It is not the same as a string with no characters, it is not the same as non-existence (NULL). It is not the same as a lie (FALSE). But it is a number that is both valid and useful. Consider an unlucky month when you have no money in your bank account. I'd expect to see $0 on the bank statement. Certainly I'd be upset if I talked to a teller and was told the account was FALSE under these conditions or that it didn't exist. But that's how things are with PHP! Zero takes the special case of being equal to a bunch of different values like FALSE and NULL. Last month I was working on a dynamically generated form. The output was a list of radio buttons, each of which mapped to a node ID in Drupal. I needed to add a final option to the list that represented a generic alternative value. There was an obvious solution, in my opinion. Node IDs start at 1 and auto increment, so I knew a node ID less than 1 would never exist. I would make my alternative value zero and interpret the result based on the value being zero or something greater. Zero is the first integer below 1 that cannot be a node ID, so it seemed a logical choice. And it all worked quite well... until I began validating the data. For example, I wanted to check if the user had actually selected an option; was the value set? Well, according to PHP:

Checks to determine if a value had been selected started to require lots of use of the '===' operator and lots of typecasting. Something that is usually indicative of problems. The logic gets muddled and the point of using a nice number like zero gets lost in extra function calls. Stubbornly, I spent thirty minutes coding these typecasting checks before I admitted defeat and backtracked. The final solution was easy. Rather than using zero, I used -1 for my alternative value. My list of options became -1, 1, 2, 3, etc... Validation checks for empty, FALSE, and NULL became easy and required no typecasting or '===' operator.

Submission became easy as well: 0) { // load a node and do something interesting } else if ($option < 0) { // apply alternative custom action } ?> (*Note: I used else if rather than else because I'm defensive. If a non-selection somehow makes it to my submission function I avoid performing the wrong action.) So I may finally have learned my lesson. I will avoid zero in the future, but I thought I'd share my experience to help others. Avoiding zero will keep your code clean and prevent the possibility of bad data. If you're mathematically inclined this may offend you. But just remember, when it comes to PHP you really have nothing to fear.

Ready to get started?

Tell us about your project