Users judge a website or web application primarily on the design and usability of the site. It doesn't matter how well written and maintainable the underlying programming is if the site is ugly, slow, buggy, or counter-intuitive. The always spot on Jeffery Zeldman explains how we can all get to a world with better sites, better work, and better-informed clients.

It’s hard to understand web design when you don’t understand the web. And it’s hard to understand the web when those who are paid to explain it either don’t get it themselves, or are obliged for commercial reasons to suppress some of what they know, emphasizing the Barnumesque over the brilliant.

Less experienced PHP programmers might read 6 PHP coding tips to write less code and think dangerous thoughts like "This is what I have to do to be an l33t coder!" The assumption that less code == better code quickly leads to hard to maintain spaghetti code. Sure it saves you time in the fun, exciting build it and show it to the client phase, but six months later when you come back to fix something, or worse yet hand it off to a colleague, you'll waste more time deciphering what you meant to do. The author addresses this with his sixth point, which advises readers to "write a comment and more readable construction."

What can you do to write readable, maintainable code - especially if you're not just a one-person operation?

Let's start with a few basics.

• Use descriptive variable names. There's no rule that your variable name has to be less than 8 characters, so don't omit vowels just to invent your own dialect. Instead of $cmpnt, just use $component. You should be using an IDE or text editor that can complete words for you. Don't get carried away though, no one wants to see $Web_Service_Component_Collection either.
• Function and class method names should also be descriptive. Methods which return a boolean true/false should be prefixed with is or has, ie isToday(), isAdmin(), hasChildren().
• Prefix functions that return a value with a get or fetch, or some other verb. Most functions should have a verb component. This avoids syntactical errors between calling a function and accessing a property in classes. For example, $user->posts, which is a property, can be confused with $user->posts(). The latter should be $user->getPosts();.

Use a code standard, and stick to it. Coding standards promote uniformity and makes it easier to understand because you don't have to parse through an individual's idiosyncrasies for naming variables, placing braces, et al.

Document functions and classes using phpdoc. Don't do it just for the auto-generated documentation, which is a nice side effect. More importantly, it will help you capture your intent for the function, parameters and their expected types, and expected return values as you're writing them, helping you when you come back to read your own code later.

Use functions to group code needed to perform a single action or test. This leads to code as in the following, albeit trivial, example:

if (is_admin($user))
{
     update_admin_log($user);
     $menu_options = get_menu_options('admin');
}
else
{
      $menu_options = get_menu_options('public');
}

Use classes to group code related to a particular set of operations or that work on an object you can model. Classes also organize your code into easier to find files, instead of monolithic files that contain many, many functions.

$page = new Page();

if (true == $user->is_admin())
{
      $log = admin_log::singleton();
      $log->update_login($user);
      $page->bind_user($user);
}

$page->show_header();

Finally, the best advice I can give is to read other people's code. Just seeing your own code reinforces bad habits. Two particularly well written PHP libraries I've run across are JpGraph, and more recently the Solar framework.