Clarence Eldefors blog Mostly about the web and technology

25Oct/120

PHP: Structure, cooperation and good practices – part 1

PHP land is very often a messy place without standards and structure. Well, that does not have to be any more. Over the years alot of tools, standards and practices have been emerging to make it a more structured place - for the good of all of us PHP developers.

Use a standardized autoloading: PSR-0

The pro of standardized autoloading is in one word interopability. It makes it easier to add source code and libraries from different sources into your project as the autoloader in your and the 3rd party source code will be compatible.

An overview of PSR-0 with links to follow for sample code and information is available at: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

Handle libraries with composer

Composer is a great tool for managing libraries. The package information is so flexible it's easy to use it with most libraries already around and completely without fuss to include libraries that added a small and simple composer.json description file to their repository.

If you start up a new project and want to include Monolog and Twig into your application; you just write the requirements up in your local composer.json file to include them like this:

{
    "require": {
        "monolog/monolog": "1.2.*",
        "twig/twig": "v1.9.2"
    }
}

The value of the package is as you can guess a version tag to set which versions you are OK with. When other packages also needs a specific version of the same library this is very useful to see that both your project and the other package are compatible to the same dependency version.

To install the packages you first download the composer PHAR file and then you just run "composer.phar install".

The package information comes from the public package repository at http://www.packagist.com. It is also easy to set up your own repository with Satis (packagist is also open source, but a bit overweight for simple inhouse repositories) and there's support for PEAR as a repo as well. If you want to add zip files or VCS repositories without the composer.json - thats also easily manageable with the package-repository in your own composer.json (see http://getcomposer.org/doc/05-repositories.md#package-2)

To get started; head over to http://getcomposer.org/

Use a coding standard

When working together with other people or companies it's important that everyone writes code the same way. The variable and function names should have the same casing, the spacing and indentation should be the same, opening braces should be at the same place.

The biggest reason is not that one way is the best to write it but that it should be easy to write code and easy to read code. If you learn to read and write code in one way, and have to change every so often during the same workday - your productivity will diminish.

There are a horde of standards out there. PSR-2, Zend, VG etc etc.

My suggestion is to follow the PSR-2 standard as that has been formed by a wider group of people and companies and is therefore easier to adapt into different types of projects.

24Oct/120

PHP, small tips and tricks #1

Purpose of this post series is to give a few tips on how to improve your code. It's not the most important practices, but some common things to see done in a less than elegant way.

For adding days or weeks to a timestamp, don't count your seconds.

DON'T:

$nextDay = $todayTimestamp + 86400;

DO:

$nextDay = strtotime('+1 day', $todayTimestamp);

The first one will fail when you move into or out of daylight savings time. An extra pro is that the second example is a hell lot more readable. Especially if you add something like 2 weeks and 4 days ('+2 weeks 4 days')

Validate and sanitize with filter_var()

Don't use regexp to filter/match an email or an URL. There's already builtin filters in PHP for it:

Example:

$email = filter_var('bob@example.com', FILTER_VALIDATE_EMAIL);

See documentation on:
filter_var()
Available filters

Tagged as: , No Comments