Development Standards: PHP

We might as well start this series off at the bottom and work our way up. So, let’s start with PHP – it’s not the base of our stack, but it’s the first element that heavily requires some coding standards in place.

As I said in the intro, this series will be about how I do things, although of course it’s all heavily based on what I’ve seen and used elsewhere, and what I’ve known to work. Given this, I’ll also talk about the toolkits and frameworks I use: Code Igniter on the server side and jQuery on the client side. I also use YUI Reset and Fonts at the top of most or all CSS.

Although it’s just as important I won’t talk about sticking to some semblance of good MVC practice when using Code Igniter. There’s plenty of that out there.

Why have development standards?

Possibly the main reason is that one person working on the code can understand what another has done. If I look at anyone else’s code and it’s formatted in a way that obfuscates its meaning, I’m possibly going to miss something key.

Looking forward, if something isn’t correctly formatted, fixing a bug is going to be that much easier if it’s easily readable. This applies whether it was written by a different person or not.

PHP tags

In view files, the short opening tag <? as opposed to <?php is encouraged, as is its logical next step <?=. Reducing clutter in view files, where front-end developers or even designers may work, is worthwhile.


All code – HTML, CSS, Javascript, PHP – should be indented correctly. All indents should be 1 single tab. I prefer to view that in my editor – whether it’s TextMate or Vim – as four columns. How you view it in your editor is a personal preference, as long as the file itself uses 1 tab.

Line endings

All line endings should be a single /n – i.e. Unix-style. In addition, add no trailing spaces to lines, and remove any that sneak in due to slack editing.

Control Structures

Including if, for, while, switch, etc:

INCORRECT in various ways



if (condition1) {
} elseif (condition2) {
} else {


Single line comments go like this:

// Check the value of foo.
$bar = isset($foo) ? $foo : '';

Multi-line, “C-style” comments:

Check the value of foo.
This is to prevent errors.
$bar = isset($foo) ? $foo : '';

Notice that the comment characters are on their own lines.


For unconditional inclusion, use require_once 'includefile.php';

For conditional inclusion, use include_once 'includefile.php';

Note: require_once and include_once are statements (or language constructs) not functions, so no parenthesis is required, or desired.

[Update: section removed as it was Subversion-specific, which has long since been replaced…]

Naming conventions

Functions and Methods

All names should start lowercase and use interCaps/camelCase

function getFooBar() {

No underscores in the middle of function names, please:


function get_foo_bar() {

Private methods should start with an underscore:

private function _getFooBar() {


Classes follow the same method as methods except start with uppercase.

class FooBar {
    function FooBar() {


Constants should be all UPPERCASE, except internally-provided ones like true, false, null;

File Format

All files should be unix format – I do not want to see any \r\n

Development Standards: Intro

I’ve decided to write an occasional series of articles on coding and development standards. It will be how I see them – the standards I myself follow – so it might not be for everyone. What it will be is a guide to what to expect if I’m working for you, and what to expect if you’re working for me.

I’ll write separate pieces for CSS, HTML, PHP and possibly for server administration-type stuff too – Apache configuration, and so on.

Expect the first instalment in the near future…