March 2, 2021
Hot Topics:

PHP Coding Style and Organization

  • By Elizabeth Fulghum
  • Send Email »
  • More Articles »

Separate PHP and HTML

One of the highlights of the PHP scripting model is that code can be freely mixed with HTML. It is one of the reasons that writing scripts is so fast and easy, and it is one of the things has helped make PHP one of the most popular Web scripting languages.

However, there is a price to be paid for utilizing this flexibility.

Files with combined HTML and PHP quickly become bulky. Anyone charged with designing the user interface for a script (even if it is yourself) has to wade through lines of programming to change or add HTML. Without experience with PHP, this can be an insurmountable challenge. And, changing the front end of an application means editing the script itself, which can easily lead to broken code.

These are just some of the reasons that many developers use template classes such as Smarty and Fast Templates. These classes allow the complete separation of programming logic and design. All the design elements of a site are broken down and stored in separate template files. Only after the PHP script has executed all of the code to generate the page are the templates called and the output finally assembled and displayed.

The end goal is to have PHP files that contain no HTML, and HTML files that contain no PHP. This separation process can become very complex, especially for the novice programmer. But there are at least two things you can do to achieve some of the same result, even without using template engines:

  • If your site has the same header, footer, and/or navigation, put the HTML for these elements in separate files. You can include the files as needed by using the include() command, or with PHP's read file functions. This allows you to update these areas site-wide, without directly editing any PHP.

  • Rather than outputting page content as you go, output it last. Assign all the dynamic content to variables, and then include these variables in the HTML for the page. This makes it easier to alter the layout of any pages later on.

Avoid Double Quotes Around Strings that Contain HTML

PHP offers a choice between using single or double quotes around strings (as well as perl's "heredoc"). The difference between the two methods is that variables are expanded within double quotes, but not within single quotes.

To avoid variable concatenation, many people get in the habit of using double quotes for strings. But HTML also uses double quotes for attributes, and so lines of code can easily wind up looking like this:

$var = "<table width=\"0\" border=\"0\" cellpadding=\"0\" width=\"100%\" cellspacing=\"0\"><tr><td style=\"font-family:Verdana;\"><a href=\"$url\">$link</a></td></tr></table>";

Strings like this should be re-written as:

$var = '<table width="0" border="0" cellpadding="0" width="100%" cellspacing="0"><tr><td style="font-family:Verdana;"><a href="'.$url.'">'.$link.'</a></td></tr></table>';

By using single quotes, the need to escape every interior double quote is removed. There is a very small performance gain that can add up over the course of a single script (especially in cases where there are no variables within the string), because the processor does not need to search the string for any variables.

Use Logical and Consistent Naming Conventions

As much comic relief as it might provide to name all your functions after the Seven Dwarves or your variables after countries, four months down the line, you won't have much luck figuring out what doc($canada); was supposed to do.

Names for elements should be short, but descriptive of the task they perform or the information they hold. If you decide to capitalize function names, maintain the same format for all of them.


It is hard to discuss coding style without devoting a few paragraphs to mention PEAR. "PEAR" is an acronym for the PHP Extension and Add-on Repository. One of the organization's goals is to amass a large collection of open source code for PHP developers to use within their own projects. Because this is a collaborate effort of massive scale, a secondary goal is to define a standard for PHP coding style. This ensures consistency within their own archives, and encourages it throughout the entire PHP community.

PEAR's guidelines go beyond general suggestions of "best practices" to establish specific and detailed rules. For example, PEAR shares the common idea that code should be indented. But they also expand on it, specifying that 4 spaces should be used for indents, and "tab" should never be used.

Is it worth bringing your code in line with PEAR? Well, probably so, unless there is some aspect you particularly abhor or are uncomfortable with. Many of these rules are adopted from C and fall in line with style guidelines from other programming languages. Though strict, they are generally easy to implement.

(PEAR's complete documentation on coding standards can be found at: http://pear.php.net/manual/en/standards.php).


Hopefully, this article has given you a little bit of insight into methods of organizing and writing your scripts so that they are more easily maintained and upgraded. Many of the concepts introduced here rely on common sense; others are learned and eventually become second nature as you continue to write more scripts.

Next time, we'll be delving into the topic of MySQL and PHP with the first of a four-part series. Stay tuned!

Liz Fulghum currently lives in Annapolis, MD where she works as a web designer for a custom shirt retailer. Liz was convinced to try PHP as an alternative to Perl; she has been a fan ever since and frequently works as a freelance developer.

# # #

Page 2 of 2

This article was originally published on April 18, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date