PHP is simultaneously the most infuriating and joyful languages I’ve ever worked with. I say “infuriating” primarily because the function names are so inconsistant. Despite the fact that I use it almost everyday, I still have to think to myself “Is it str_pos or strpos? str_split or strsplit?” On the other hand, occasionally I’ll stumble across a gem that perfectly solves the problem at hand with a single line of code.
Here’s a short list of cool features that might have slipped under your radar as well:
- Use ip2long() and long2ip() to store IP addresses as integers instead of strings in a database. This will reduce the storage space by almost a factor of four (15 bytes for char(15) vs. 4 bytes for the integer), make it easier to calculate whether a certain address falls within a range, and speed-up searches and sorts (sometimes by quite a bit).
- Partially validate email addresses by checking that the domain name exists with checkdnsrr(). This built-in function checks to ensure that a specified domain name resolves to an IP address. A simple user-defined function that builds on checkdnsrr() to partially valid email addresses can be found in the user comments section in the PHP docs. This is handy for catching those occasional folks who think their email address is ‘joeuser@wwwphp.net’ instead of ‘joeuser@php.net’.
- If you’re using PHP 5 with MySQL 4.1 or above, consider ditching the mysql_* functions for the improved mysqli_* functions. One nice feature is that you can use prepared statements, which may speed up queries if you maintain a database-intensive website. Some benchmarks.
- Learn to love the ternary operator.
- If you get the feeling that you might be reinventing the wheel during a project, check PEAR before you write another line. PEAR is a great resource that many PHP developers are aware of, yet many more are not. It’s an online repository containing over 400 reusable snippets that can be dropped right into your PHP application. Unless your project is trully unique, you ought to be able to find a PEAR package that saves at least a little time. (Also see PECL)
- Automatically print a nicely formatted copy of a page’s source code with highlight_file().This function is handy for when you need to ask for some assistance with a script in a messageboard, IRC, etc. Obviously, some care must be taken not to accidently show your source when it contains DB connection information, passwords, etc.
- Prevent potentially sensitive error messages from being shown to users with the error_reporting(0) function. Ideally error reporting should be completely disabled on a production server from within php.ini. However if you’re on a shared webhost and you aren’t given your own php.ini, then your best bet is to add error_reporting(0); as the first line in each of your scripts (or use it with require_once().) This will prevent potentially sensitive SQL queries and path names from being displayed if things go awry.
- Use gzcompress() and gzuncompress() to transparently compress/decompress large strings before storing them in a database. These built-in functions use the gzip algorithm and can compress plaintext up to 90%. I use these functions almost everytime I read/write to a BLOB field within PHP. The only exception is when I need full text indexing capabilities.
- Return multiple values from a function with “by reference” parameters. Like the ternary operator, most PHP developers who come from a more formalized programming background already know this one. However, those who’s background is more HTML than Pascal, probably have wondered at one time “how do I get multiple values back from a function I wrote, even though I can only use one return value?” The answer is that you precede a variable with “&” and use it “by reference” instead of “by value”.
- Fully understand “magic quotes” and the dangers of SQL injection. I’m hoping that most developers reading this are already familiar with SQL injection. However, I list it here because it’s absolutely critical to understand. If you’ve never heard the term before, spend the entire rest of the day googling and reading.
If you have to worry about number 8, then find a new database.
Uhh… #2 is wrong.
The domain in an email address does not need to resolve to an IP to be valid. An e-mail address domain can be perfectly good without an IP address, so if you follow this “tip” you will reject some perfectly good e-mail addresses.
To properly validate the domain in an e-mail, you must do an MX record lookup.
Only problem with checkdnsr is that its an apache pacific function. So if you are like most, and first create your code on Windows and then upload it to an apache server, it doesn’t work on your test server so you can never tell what will happen.
“Learn to love the ternary operator.”
Too much love can be a problem.
Cheers
Why only 10 things?
2. I would check for MX, A, CNAME entries for a host
3. I think it’s better to use PDO now if you want to make your code database-independent to some extent.
I’m still learning PHP, but I’ve already come to love the ternary operator for simple (non-nested) assignments…it keeps code simpler and less visually jarring. To help visually parse the ternary statement, however, I place parens around each of the pieces, like so:
$var = (testvalue) ? (truevalue) : (falsevalue);
which makes it quite easy to read.