Some tips for PHP developers

I want to publish a small collection of tips for modern PHP developers. I deliberately do not associate them with certain frameworks, libraries, and so on. I hope that my advice will help someone better understand PHP, learn to use it better. Some of them may not be specific to PHP, but for programming in general.

Fast PHP code contains a minimum of PHP.

Perhaps this advice will suit many developers in interpreted languages. PHP contains a huge number of native (written in C) functions. Their speed exceeds any PHP counterpart. Try to use them instead of PHP-analogues.

In fact, of course, it is difficult to keep in mind all the built-in PHP functions. I made a rule for myself: before writing a function, try to look for it in the documentation. In most cases, the native function is found.
')
Examples:
1. It was necessary to parse the url into components. I try not to use regular expressions for such things. The function was found quickly: parse_url .
2. Parse the url with the parse_url function successfully, now it was necessary to parse the GET parameters from the url. And for this, the function was found: parse_str .

Extensions work faster than PHP code.

For PHP there is a repository of extensions: PECL . There you can find a lot of interesting things. Extensions are also written in C and work faster than PHP counterparts. For example, I use apc and yaml . I think, and you can find there a lot of interesting things for yourself.

Use third-party code carefully.

One of the biggest problems I encountered in products implemented in PHP is the high connectivity with third-party code, which does not allow replacing one third-party tool with another. In fact, this advice is related to the general approach to minimizing connectivity, but the problem with external components is particularly acute.

If you decide to use a third-party library, firstly make sure that there is a special directory for third-party tools in the folder structure of your project. Do not mix the project code and the code of third-party tools.

Next, create your own classes for working with the library, which would proxify the calls to the library, but the interface of these classes does not have to match the interface of the library. It should be shared and not tied to this particular library, so that by changing the logic in these classes, you could switch to another library without rewriting the project itself.

If you are faced with a case where libraries should be replaceable, then you need to write interfaces, providers or even abstract factories.

In any case, a direct connection between the project and third-party tools cannot be allowed; any other solution will look more profitable.

PEAR

Whether you use PEAR or not, in any case you should know what it is. PEAR is a PHP class repository for solving many common tasks. It is located at this address: pear.php.net/packages.php . I would not say that classes in PEAR differ in any particular quality, or support, or anything else. In essence, this is just a useful class repository, cleaner than phpclasses.org. To install and remove PEAR packages in PHP, there is even a " pear " command, but with the same success, PEAR packages can also be put in the application folder and used.

Use PHP 5.3.

If you are not working on projects where hosting is chosen for you, then definitely switch to PHP 5.3.

The most important innovation of this line of PHP is anonymous functions. Now instead of:

function my_temp_map ( $ x ) {
return $ x + 1;
}
$ result = array_map ('my_temp_map', $ arr );

You can write:

$ result = array_map ( function ( $ x ) { return $ x + 1;}, $ arr );

Moreover, now you can declare sub-functions and use closures:

public function myMethod ( $ data ) {
$ subFunction = function () use ( $ data ) {...};
$ x = $ subFunction ();
}

In addition to anonymous functions, a lot of interesting things were added: php.net/ChangeLog-5.php

Next I will go more into specifics.

Do not use the "@" operator.

The "@" operator used to hide errors when executing a particular instruction is bad for two reasons: firstly, it is slow, and secondly, getting used to it is undesirable, because when using it to function calls, you will automatically block errors in the called function that may be undesirable.

Often the "@" operator is used when accessing an associative array in cases where there is no certainty about the existence of a particular key. In this case, you can do this:

$ x = isset ( $ arr [ 'x' ])? $ arr [ 'x' ]: null ;

Do not use cp1251.

Comrades who have not yet switched to utf8! Go over! The earlier the better.

When working with utf8, you need PHP compiled with the mbstring extension (included in the normal set when compiling).

Work in mode E_ALL | E_NOTICE | E_STRICT.

It is in this mode that error_reporting should be set if you start working on a project. Notices are something that is often ignored and at the same time that which most often contains errors. If you access an undefined variable, an array with a non-existent key, etc., NOTICE will occur. If you are not sure of the existence of a variable / key in an array, you should check with the isset operator.

Reread phpmanual.

The PHP development team has implemented a huge amount of functionality that can be used in your project. Most of it is described in the official documentation, which is constantly updated. Refresh your knowledge, multiply them, regularly reviewing the manual.

At a minimum, you need to know all the php.ini settings and what they affect.

Evolve.

Read the code. Yes. Read the code of the tools you use. Read the code for the frameworks you are developing. It is very interesting and useful. You will also learn that this code is not written by gods, but by programmers like you. And if you are careful, you will find a lot of sub-optimal moments or mistakes.

Write to. Write your tools, even if there are ready ones, if there is a need for it, do not build crutches to customize third-party tools for your tasks. Think frameworks are written by more experienced people than you? Check out the code for these frameworks.

This ends my advice, thank you for your attention.