domi.co.uk – technology, music, photography, news

Spot the deliberate mistake:

An interesting idea is presented on “for a beautiful web” regarding how best to deal with IE6 and its many failings. Universal Internet Explorer 6 CSS proposes that IE6 always gets sent a standard look and feel, so that the experience for its users is not bad – just not the full shebang. It’s clear it has been designed, rather than sending plain CSS-less HTML, but it’s very sparse.

Personally, I like the idea. I have done something similar on more than one occasion. I haven’t taken it to the same level, possibly, but I’ve treated IE6 in a similar way to how I treat screen readers for example: make sure all the content is available, and is usable. What follows are a couple of screen shots of redamc.com, first from Safari 4, then from IE6. (The Safari 4 shot is representative of all modern browsers, though.) The design basically revolves around having all the content on one page, in nicely scrollable boxes. In IE6, this was not well supported, and the decision was taken to make the layout more “blog-like”. All the content is the same, however.

First, Safari 4:

And IE6:

Beta 3 is out and the new OS fixes the non-working Youtube from the previous beta.

[Update: and also breaks syncing, which now hangs on "Syncing contacts..."]

[Update2: Seems like the contacts syncing hang was a temporary issue...]

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 <?=$var?>. Reducing clutter in view files, where front-end developers or even designers may work, is worthwhile.

Indentation

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){
    //action1
}
elseif(condition2){
    //action2
}else{
    //action3
}

CORRECT

if (condition1) {
    //action1
} elseif (condition2) {
    //action2
} else {
    //action3
}

Another example:

for ($i = 0; $i < 10; $i++) {
    ...
}

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

You are strongly encouraged to always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

A switch block:

switch (condition) {
    case 'one':
    action1;
    break;

    case 'two':
    action2;
    break;

    default:
    action3;
    break;
}

Function Calls

Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon. Here’s an example:

INCORRECT

$var=foo($bar,$baz,$quux);

CORRECT

$var = foo($bar, $baz, $quux);

As displayed above, there should be one space on either side of an equals sign used to assign the return value of a function to a variable.

Function Declarations

We usually try to put the arguments with default values at the end of the list:

function fooBar($var1, $var2 = '') {
    if (condition) {
        statement;
    }
    return $value;
}

Arrays

Always use spaces:

$array = array('val1', 'val2', 'val3');

If the array is even remotely large, break it into separate lines:

$array = array(
    'key1' => 123,
    'key2' => 'foo',
    'key3' => getValue('bar'),
);

Notice the extra comma after the last element – this means we can rearrange the elements or add a new element with worrying about commas between elements. (This only works with PHP.)

Comments

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.

Includes

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.

Metadata

Every applicable file should use an Id keyword:

<?php
// $Id$

which gets expanded by Subversion to

<?php
// $Id: codingstandards 758 2008-05-15 01:35:58Z dom $

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:

INCORRECT

function get_foo_bar() {
    ...
}

Private methods should start with an underscore:

function _getFooBar() {
    ...
}

Classes

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

class FooBar {
    function FooBar() {
        ...
    }
}

Constants

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…

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…

I just got a new drive for my MacBook (MacBook2,1 – black) and am quite pleased with the simplicity of the process. First up, I didn’t need to add a jumper to throttle the SATA II drive down to SATA I speed. I put it in, it was recognised OK. The drive is a Seagate ST9320421ASG.

Secondly, the restore from Time Machine was pretty damn simple and effective. It’s always the same question with backups – if you don’t test them, do you know they’ll work? I’ve grabbed individual files from Time Machine and that seemed fine, but I had no way of knowing, without having a new drive with which to test, if a system restore would work. It did. Just boot with the DVD (or a copy of it on an external drive, if your DVD drive doesn’t work, like mine) and choose to restore from Time Machine. Just pick which backup to use, pick where to restore it to and wait. I suppose it took about an hour.

Once that’s done, reboot with the new system.

The only things I noticed awry were that my hosts file wasn’t there and that my Downloads directory wasn’t either! Seems a bit odd… Anyway, copy old hosts file to new location, copy old Downloads directory to home dir and sorted. I need to look into the missing directory issue, but all in all, not too bad an experience.

[Update: small, possibly even unrelated error: the firewall seemed to have Ruby blocked for some reason, even though it was listed as allowed - just switched it to block, then back to allowed and it worked.]

[Update2: the Downloads directory wasn't there because I, er, set it to be excluded... ahem. I'd forgotten about that.]

I’m in the middle of the first phase of building a new webapp and like most web developers (I would bet) when I show someone what I’ve done, it’s not apparent what marvels of engineering I’ve pulled off! So, in order to actually give a quick run-down of where we’re at with the application, I thought about making a screencast of the login, profile creation, module, video upl– well, I’ve said too much already ;)

After thinking about that for a bit, I wondered if any methodologies, agile or otherwise, use screencasts specifically as a tool. I could just Google it, I know. In any case I think it’s a nice way of showing progress on the development – or bugs in the app.

As the first example of my Tienda.co.uk project, we’ve just launched slant1996.com which sells slightly mad t-shirt designs!

I recently helped out updating a friend’s online shop: Nunoya in Barcelona. As well as the obvious stock of kimono and other clothing items, they have some cool accessories. But my favourites are the Kokeshi, which I don’t remember having seen before – slightly mad (in a good way) dolls that look a bit like Russian dolls, but Japanese. And they don’t contain smaller versions of themselves, so actually, they’re nothing like Russian dolls!

[update: forgot to mention I did some photos of Sofia in kimonos for the site...]

This is probably an oldie-but-goodie to a lot of web devs, but as search indexing bots don’t always send HTTP_ACCEPT_LANGUAGE to the server with the request, it will cause an error if you depend on its presence, which can and will be reflected in the search results, even though not in “any” browser.

Birthday girl.

Lovely redesign of jquery.com.

I’ve just been trying Mailplane which is a nice OS X desktop app for Gmail.

• Drag and drop to attach a file? Check!
• Automatically take and send screenshots? Check!
• Send pics from iPhoto? Check!
• Optionally optimise photo attachments? Check!
• Growl integration? Check!

The screengrabbing and sending in one swift move is very nice, if you end up doing that sort of thing a lot.

But, why provide an interface (this is just a wrapper around Webkit, after all) to one of, if not the best keyboard-controllable web app there is, then not allow the same shortcuts? All those years (yes, years!) beating Gmail shortcuts into my fingers! Actually, it’s not so much the years using Gmail as the previous years using Mutt, and for that matter vi/vim, that made these shortcuts automatic. That’s why, when I first looked at Gmail as a possible replacement for Mutt, the fact that there was no change of habit really impressed me. (And that includes the conversations/threading model, too.)

Well, nice try uncomplex, but I’ll stick to for my Gmail window for now.