20 Aug 09 20+ PHP web developer tips

This is my personal collection of tips for web developers. This is supposed to grow big! Please be patient and link this only when it’s decent or at least half finished.

1 – Hide errors from visitors, not from you

When developing you will want to see all possible errors. I’ll use Rasmus (creator of PHP) words:

You should always develop with all possible messages turned on. eg.

error_reporting = E_ALL | E_STRICT

And before you put your site in production make sure you do:

display_errors = Off

And send all error messages to a log file:

log_errors = On
error_log = “/var/log/php_errors”

2 – UTFB, Use The Fucking Braces!

Never, ever ommit braces. This is a mean, cheap and lazzy (the bad laziness) practice. Braces add to code readability and that should be your primary goal when coding.

Bad:

if (userIsLogged()) showPrivatePage();
else requireLogin();

Good:

if (userIsLogged()){
    showPrivatePage();
}
else
{
    requireLogin();
}

Where you want to position the braces its up to you and I’m not interested in your preference. =P

3 – Register globals. Don’t do it for the sake of PHP

Register globals is a MoNsTeR that chews variables from $_ENV, $_GET, $_POST, $_COOKIE and $_SERVER and then spits the result as global variables into global scope.

It’s the easiest way to get really strange application behaviors (bugs) and security holes (big ones). I’m sure whoever invented it had good intentions but it didn’t worked well.

Always be clear from where you are reading input and you will also get a bonus to redability. Use the $_POST, $_GET, $_SERVER, $_ENVand $_COOKIE instead.

Bad:

// with magic quotes turned on, $admin could come from many sources
if ($admin == true)
{
    showAdminPage();
}
else
{
    showPermissionDenied();
}

Good:

if (isset($_SESSION['admin']) and $_SESSION['admin'] == true)
{
    showAdminPage();
}
else
{
    showPermissionDenied();
}

4 – Avoid @error suppresion

You can hide errors from PHP by using @ like this:

Bad:

if (trim(@$_POST['name'] == '')
{
    $error = 'Please type your name.';
}

There are two problems with using PHP’s @ error suppression. The first problem is that for each @, PHP have to change error_reporting level to 0, processes the expression proceding the @ character and then return the error reporting back to the previous level. This is expensive!

The second argument against error suppression is that it can often be the source of debugging nightmares because it hides errors from you, even fatal errors commonly produced by mistyping function names and unexpected behavior. Remember the first tip: Hide errors from visitors, not from you.

There are however, a few cases where it is okay to use the error suppression. Some examples of good and bad usage:

Bad:

if (User::authenticate(@$_POST['name'], @$_POST['pass']))
{
    header('Location: /admin/');
    exit;
}

Good:

if (isset($_POST['name'], $_POST['pass']) && User::authenticate($_POST['name'], $_POST['pass'])
{
    header('Location: /admin/');
    exit;
}

Good:

// Suppress error sending e-mail because the function already return if the operatio nwas a sucess or no
$mailSent = @mail($to, $subject, $message, $headers);

Tip: If you use custom error handler, you can detect error suppression by checking if PHP lowered the errro_reporting level just before calling your error handler:

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
    // If error has been supressed with an @
    if (error_reporting() == 0) {
        return true;
    }

    // >>>>> Your error handling code here <<<<<

    // By returning true we are tell PHP not to execute its internal error handler
    return true;
}

$oldErrorHandler = set_error_handler("myErrorHandler");

I’ll write the tips below when I have the time…

5 – Autoload classes

6 – Separate code from HTML (logic from view)

7 – Framework: should you use one?

8 – Request only what you need from database: avoid SELECT *

9 – The art of code commenting

10 – Have a clone from production environment if possible

11 – Use a database connection wrapper

12 – Code performance optimization: leave it to the end and when really necessary

13 – Keep It Simple Understandable

14 – Don’t Repeat Yourself

15 – Where to get help

16 – Get concentrated (enter the zone)

17 – Keep updated

18 – Avoid distractions and time killers at all costs

19 – Stop spamming the Internet

Don’t start or participate in any flamewar. People don’t need want to know what editor/tool/framework/operational system/distro/lib/language/coding standard/keyboard/laptop/hand/finger/toilet paper you use or like unless:

a) Someone ask you

or

b) Your information will add some value

20 – Debugging for designers

21 – Debugging for developers

22 – What is MVC? Should you use it?

23 – UTF-8 encoding for breakfast, dinner and launch

24 – Don’t use short tags: <?= and <%

More to come… I’ll keep updating this post.

Comments

1. Claudio | 29 Aug 2009 8:37 pm

   Hi man, one tip: stop the use of short php tags (), in php6 this will be not supported…
   H*ly sh*t!

   ^^’

2. Bruno Cassol | 30 Aug 2009 4:38 pm

   Claudio,
   Its a very good advice not to use short tags and I’ll add them to this post.

   But note, PHP 6 will still support short tags but they will be deprecated then.

   Thank you!

Add a comment

Name (required)

E-mail (will not be published) (required)

Website