A few tips for PHP developers

    imageI want to publish a small collection of tips for modern PHP developers. I deliberately do not associate them with certain frameworks, libraries, etc. I hope that my advice will help someone better understand PHP, learn how 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 analogue in PHP. Try to use them instead of PHP analogues.

    In fact, of course, it's hard to keep in mind all the built-in PHP functions. I developed a rule for myself: before writing a function, try looking for it in the documentation. In most cases, a native function is found.

    Examples:
    1. It was necessary to parse url into components. I try not to use regular expressions for such things. The function was found quickly: parse_url .
    2. Parse_url function was able to parse url successfully, now it was necessary to parse GET parameters from url. And for this, a function was found: parse_str .

    Extensions are faster than PHP code.

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

    Use a third-party code carefully.

    One of the biggest problems that I have 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 associated with a general approach to minimizing connectivity, but the problem is especially acute with third-party components.

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

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

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

    In any case, you can not allow a direct connection between the project and third-party tools, any other solution will look more profitable.

    PEAR Whether

    you use PEAR or not, you should know what it is anyway. PEAR is a repository of PHP classes for many common tasks. It is located at this address: pear.php.net/packages.php . I would not say that classes in PEAR are distinguished by any special quality, or support, or anything else. This is essentially just a useful class repository, cleaner than phpclasses.org. There is even a " pear " command to install and remove PEAR packages in PHP , but with the same success, PEAR packages can also be simply put into the application folder and used.

    Use PHP 5.3.

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

    The most important innovation of this PHP line 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, you can now 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 the specifics.

    Do not use the "@" operator.

    The @ operator used to hide errors when executing a specific instruction is bad for two reasons: firstly, it is slow, and secondly, getting used to it is undesirable, because when you use it to function calls, you will automatically block the occurrence of 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 key. In this case, you can do with this design:

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


    Do not use cp1251.

    Comrades who have not yet switched to utf8! Come on! The sooner the better.

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

    Work in E_ALL mode | 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 often ignores and at the same time that most often contains errors. If you accessed an undefined variable, an array with a nonexistent key, etc., then NOTICE will appear. If you are not sure about the existence of the variable / key in the array, you should check it with the isset operator .

    Re-read 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 official documentation, which is constantly updated. Refresh your knowledge, increase it by 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 for the tools you use. Read the code of the frameworks you are developing on. It is very interesting and useful. You will also learn that it is not the gods who write this code, but the same programmers as you. And if you are careful, you will find a lot of non-optimal moments or mistakes.

    Write. Write your tools, even if there are ready ones, if there is a need for this, do not build crutches to tailor third-party tools to your tasks. Do you think that more experienced people write frameworks than you? Check out the code for these frameworks.

    This ends my advice, thanks for your attention.

    Also popular now: