Php

PHP like many other programming languages has facilities to handle exceptions. Using them is pretty easy, but sometimes lazy programmers seems to misuse them to suppress error messages. A try/catch in PHP is usually constructed something like this:

try {
	// Something can go (horribly) wrong...
} catch {
}

The lazy programmer may leave the catch empty, but frankly you should never do it. When you’re doing something - try’ing - it’s for a reason, and if it fails, someone quite possible need to know - the end user, a log file for the sysadm or someone else. Never leave your catch empty, and if you really have a case, where it’s applicable, at least leave a comment in catch block explaining why it’s okay to do nothing.

In PHP when you have a string and want to find out if it contains another string, there are a few ways to do it. You can use regular expressions, use the strstr functions and a few other methods. The easiest way though is probably by using strpos, which returns the number of the character containing the first occurrence of the thing you’re looking for - and false if the string isn’t found.

When using memcache from PHP, you can save values with either set or replace. You can probably safely ignore the replace method:

“Memcached::replace() is similar to Memcached::set(), but the operation fails if the key does not exist on the server.”

- PHP Documentation

In PHP many things can be done several different ways. Picking which way to do something may be a matter of personal taste or habit. Sometimes however, things may be much clearer for the next developer, if you choose one way over another.

A very simple example of this, is adding a new item to an array. Often I come across this construct:

$valuepairs[] = 'Some value'

It’s valid and compact syntax, but in terms of clarity, I’d prefer this construct anytime:

A url may contain a hash/an anchor reference. If you need to remove it from url, it’s quite easy. Here’s a short recipe on how to do it in PHP (including a little test input):

$urls = array(
	'http://example.com/',
	'http://example.com/#test',
	'http://example.com/?id=1',
	'http://example.com/?id=1#test',
	'http://example.com/?id=1&id2=2#test#test',
	'http://example.com/?id=1#test#test'
);

foreach ($urls as $url) {
	if (strpos($url, '#')) {
		$url = substr($url, 0, strpos($url, '#'));
	}
	echo $url, "\\n";
}

Apart from removing the hash ending from urls, the function can naturally also be used on any number of other similar cases, where you need to trim a string.

So your current website - if running PHP - and it seems to work just fine. I am however working on a project, where the new servers are running on a 64 bit version of the OS. This change seem to cause a number of potential issues, and as there didn’t seem to be a resource collection the issues, I’ll try to post a few notes on the experience. Please feel free to add applicable notes and links in the comments.

Just a word of warning when using PHP and Mysql - if you’re trying to make efficient code and not utilizing all sort of frameworks and abstractions, you might be in for a small surprise in a default setting.

Usually is slightly lazy and often use the mysql_fetch_assoc function. It provides each row as an associative array, and is quite convenient to work with. Recently however while optimizing some code, I figured I’d switch to using mysql_fetch_array assuming it should be more efficient. The logic being that mapping hash keys to array values wouldn’t be needed and it should use less memory.

In most web applications there’s a host of functions (or methods if speaking in the object-oriented world). It’s widely recognized, that it’s probably a good idea to name them something, which may suggest the purpose or functionality of what the function is doing, but often developers seem to fail at making a stringent naming convention. Before starting on your next big development adventure, here are a three suggested rules for naming functions.

I’ve been developing web applications for some years now, and while I make no claims to being the world greatest developer, I do figure, that I do have some solid experience which may help others

• or at least encourage thoughts and discussion. This is the first in a series of posts, and while it may be from a PHP developers point of view, it may applicable to other programming languages, and maybe even beyond web applications. Here are my four tips on function parameters.

Always have a default value on all parameters

Functions parameters are often used as input to SQL queries, calling webservices or computations. Null or non-existing values often tend to break these things and throws horrible messages to the end-user.

I’ve been refactoring and refactoring some old code, and it’s kind of odd what short-cuts (or even time bombs), you’ll find in code, which apparently wasn’t supposed to live on for years. In a now retired CMS system, we had an issue every new year, when some kind of bug would reset all “schedules” for upcoming stories and content. No-one ever got around to fix it, as the system was soon to be decommissioned - but sadly the bug did survive a few years anyway.