The visitors to your site have priority. Your job is to put the effort into getting them the information they want as rapidly as possible. On the other hand, your time is more valuable -- indeed, more expensive -- than the computer's.

If you can save yourself five minutes' work at the expense of an extra millisecond of processing time on a page, that is a good investment that would continue to pay off even after the page has been processed  three hundred thousand times. You can put those five minutes into something more productive, such as  seeing if there is a way to save twenty milliseconds when processing the page.

It's not just a matter of  being able to fill a user's request as fast as possible -- considering all the opportunities for delay between  your server and their browser, mere speed may not be that much of a factor. (It is if you have an extremely  busy site, but if that's so then as you've seen your bottlenecks are probably elsewhere.) It's a matter of if  you can get the existing page to run faster, you can start wondering what else the page could do for your site's audience.

  But how can you achieve such a transfer of workload? It's not enough to put more and more onto the  computer if it doesn't relieve you of any work. A crucial way to save programming time is to write code  in such a way that reading it is as hassle-free as possible.

  Now, there are few issues more likely to spark heated debate than things like how much to indent by,  which bits to indent, where the braces should go, and whether elses should be appear on the same line  as adjacent braces, like this: } else {.

Things can get ugly. And if and when you've decided these things,  you still have to decide things such as naming conventions for variables, functions, objects, and classes;  whether to declare a method as protected static or static protected (it matters if you ever have to do a search-and-replace); whether you declare global $foo;, use "$GLOBALS[`foo'], or ban the use of  global user variables outright; and where to put comments and what to write in them; not to mention more substantive issues such as how your code is divided into files.

Avoid "code beautifiers" -- programs that take a file of source code and return it reformatted according to some set of standards. At least, don't rely on them. Your code should be beautiful to begin with; other-wise, you're missing the point of having the standards. Use them if you have old code or code from else-where with different standards that you wish to make consistent with your own, or to make your code consistent with someone else's standards. But don't work by cheerfully knocking out a mess because you can just use the beautifier on it afterwards to make it pretty.

PEAR Coding Standards

One way to cut through at least some of the tangle is to adopt an existing style guide. While you could  adopt a guide developed for a language with a similar syntax like C, C++, or Java, the fit may not be  ideal. For example, it's not necessary for the way you name variables to be distinctly different from the  way you name functions; the former are already distinguished by the $. Instead, you could adopt a PHP-  specific standard, of which the most widespread is that described in Chapter 4 of the PEAR manual.

  Unless you're putting together a repository of code submitted by the public, as is the case for PEAR  itself, following PEAR style to the letter may not be appropriate. For example, PEAR style requires that  each source file begin with a block of commentary that stating such things as authorship and licensing.  For a large in-house application that won't be getting distributed, a distribution license is pointless, nor  would it be necessary to list all of the developers on every file. However, the PEAR standard serves as a  starting point.