1. diel - Štandardy jazyka PHP - Úvod a PSR-1

Vitajte u prvej lekcie kurzu, v ktorom sa budeme zameriavať na správny zápis PHP kódu. Štandardy sú v programovaní veľmi podceňované a málo kto si je vedomý toho, že zle napísaná webová aplikácia je nekompatibilný s okolitým svetom a nesie si bremeno problematického alebo dokonca nemožného využívanie knižníc tretích strán.

Prečo sú štandardy dôležité

PHP je ako jazyk veľmi šikovné a rozšírené. Problém v ňom však nastáva pri tvorbe väčších aplikácií ako sú komplexné informačné systémy, CRM, rozšírenejšia CMS systémy o ďalšie moduly, e-shopy a podobne. Takéto aplikácie:

• Sú napísané objektovo (veľká aplikácia je bez logického členenia funkčnosti do objektov neprehľadná)
• Obsahujú veľké množstvo tried
• Vyžadujú premýšľanie nad architektúrou (nestačí bezmyšlienkovite pridávať ďalšie kód)
• Využívajú knižnice tretích strán

Tieto veľké aplikácie sa často nepíšu na zelenej lúke (od nuly), pretože by to bolo veľmi nákladné. Skladajú sa ako stavebnica z rôznych knižníc, frameworkov, modulov a pluginov.

Uveďme si reálny príklad. ITnetwork je napísaný na jednoduchom MVC frameworku v PHP, pre prácu s databázou používa knižnicu Dibi, pre parsování článkov používa knižnicu Texy !, pre zvýrazňovanie zdrojových kódu FSHL, ďalej používa ďalšie množstvo menších knižníc pre prácu s obrázkami, textom a podobne. Keď by sme chceli na ITnetwork pridať napr. Výpis dát do tabuľky s radením, nebudeme zbytočne písať vlastné dátovú tabuľku, ale použijeme ďalšie hotovú knižnicu, ktorú niekto vyrobil.

Tieto knižnice, s ktorými v aplikácii pracujeme, pochádzajú od rôznych autorov (výrobcov). Keď nejaký výrobca píše nekvalitné alebo neštandardné kód, môže byť problém jeho knižnicu použiť alebo môže jej použitie dokonca rozbiť nejakú inú časť našej aplikácie. Štandardy samozrejme nie sú dobré len pre výrobcov knižníc, ale aj pre nás, aby sme mohli na našej práci stavať u ďalších projektov, ktoré budú postavené napríklad na inom frameworku.

Ako sa aplikácia stále zväčšujú a stále sa zvyšuje potreba použitia knižníc, zvyšovala sa aj potreba nejakého jedného spoločného štandardu, ktorý by zabezpečil, že do seba knižnice (časti našej stavebnice) budú správne pasovať.

Php Framework Interop Group

Práve problém chýbajúceho štandardu pre PHP rieši PHP Framework Interop Group. Ide o združenie programátorov najvýznamnejších frameworkov pre PHP, ktorí vytvorili súbor niekoľkých štandardov a dobrých praktík, ako by mal PHP kód vyzerať. Združenie vzniklo na konferencii php | tek v roku 2009 a v súčasnosti je jeho členmi bez mála 50 autorov významných projektov.

Hoci sa nejedná o oficiálne PHP štandard, dodržiavajú ho tak významní hráči, že ho môžeme za oficiálny považovať a je tiež možné, že sa oficiálnym raz stane. Členmi PHP-FIG sú totiž napr. Vývojári frameworkov: Symfony 2, Zend Framework, PEAR, Doctrine, CakePHP, phpBB, Joomla a ďalšie.

Php Specification Request (PSR)

PHP-FIG vydala už niekoľko štandardov a každý sa týka iné problematiky. Jednotlivé štandardy sú pomenované ako PSR-N, kde N je číslo štandardu. Číslovanie začína od 0. Každý štandard je rozdelený do niekoľkých časti a podcastov pomocou nadpisov a podnadpisov. Štandardy sú veľmi jednoduché, vecné a jednoznačné. Sama skupina používa pre zápis štandardov odporúčaní RFC 2119, ktoré pomocou slov ako "musíte", "nesmiete", "je vyžadované" a podobne zaistí maximálnu zrozumiteľnosť a jednoznačnosť celej špecifikácie (originál odporúčanie je k zhliadnutiu tu: http: //www.ietf .org / rfc / rfc2119.txt, jednotlivé štandardy potom tu: http://www.php-fig.org/).

PSR-1

Standard PSR-0 zatiaľ preskočíme a začneme rovno PSR-1, ktorý je úplným základom špecifikácie. Predpisuje ako správne používať PHP direktívu a ako pomenovávať triedy a ich prvky. Poďme sa na neho pozrieť. Štandardy sa budem snažiť prekladať čo najpresnejšie, ale občas vynechám nejaké redundantné pasáže, ako zhrnutie a podobne.

Súbory

Štandard predpisuje ako pracovať s PHP súbory a to v nasledujúcich bodoch.

Php tagy

V PHP súboroch sa MUSÍ používať iba dlhé tagy <? Php alebo krátke echo <? =.

<? = Nie je short tag, hoci si to ľudia často chybne myslia, a je úplne bezpečné ho používať. Naopak by sme nemali používať len <?, čo je short tag a nie je zaručené, že je server nastavený tak, aby ho spracoval.

Kódovanie

Všetky PHP súbory MUSÍ byť kódované iba v UTF-8 bez BOM.

O samotnom UTF-8 je určite zbytočné sa rozpisovať. BOM je skratka Byte Order Mark (označenie poradí bajtov). Jedná sa o dobrovoľný znak na začiatku súboru, ktorý špecifikuje či sú použité pre uchovanie znakov 16bitová alebo 32bitová čísla. V UTF-8 nemá žiadny význam a preto sa často vynecháva, pretože môže spôsobiť nepríjemné problémy.

Vedľajšie účinky (Side effects)

Súbory by MALI iba deklarovať symboly (triedy, funkcie, konštanty, ...) a nespôsobovať žiadne vedľajšie účinky. Alebo by súbory MALI spúšťať logiku, ktorá má za následok nejaký vedľajší účinok. NEMALI by ale robiť oboje naraz.

Vedľajším účinkom sa myslí spustenie logiky, ktorá nie je priamo spojená s deklaráciou tried, funkcií, konštánt a podobne. Nemali by sme v jednom súbore napr. Deklarovať funkcie a zároveň ich spúšťať. Ľahko by sa nám stalo, že by sme si chceli taký súbor s funkciami načítať, aby sme ich mohli používať a zabudli by sme na to, že nám samotné načítanie súboru už niečo spustí alebo prednastaví. To je práve ten vedľajší účinok, ktorý nás v lepšom prípade prekvapí a v tom horšom rozbije aplikáciu.

Príklad takéhoto súboru, ktorého načítanie spôsobuje vedľajšie účinky, je nasledujúci (pozri štandard):

<?php
// vedlejší účinek: změna ini nastavení
ini_set('error_reporting', E_ALL);

// vedlejší účinek: načtení souboru
include "file.php";

// vedlejší účinek: generování výstupu
echo "<html>\n";

// deklarace
function foo()
{
    // tělo funkce
}

Mali by sme mať teda len súbory s funkciami a triedami a potom súbory, v ktorom je načítame a používame. Napr. takto:

Súbor matematika.php:

public function secti($a, $b)
{
    return $a + $b;
}

public function odecti($a, $b)
{
    return $a - $b;
}

...

Súbor vypocet.php:

require('matematika.php');

echo(secti(5, 6));

Deklarácia logiky a jej spustenie je oddelené a nedochádza k nechceným vedľajším účinkom.

Pri deklarácii môžeme použiť podmienky, ak sa týkajú deklarácie. Nie je to potom brané ako vedľajší účinok:

<?php
// deklarace
function foo()
{
    // tělo funkce
}

// podmínečná deklarace *není* vedlejší účinek
if (! function_exists('bar')) {
    function bar()
    {
        // tělo funkce
    }
}

Menné priestory a názvy tried

Menné priestory a triedy MUSÍ spĺňať štandard PSR-0.

O štandardu PSR-0 si ešte povieme viac na konci seriálu. Teraz nám bude stačiť, že predpisuje, že každá trieda MUSÍ byť v samostatnom súbore, ktorý je súčasťou nejakého menného priestoru. Každý menný priestor MUSÍ začínať názvom jeho autora / výrobcu (anglicky vendor). Pozrime sa na ukážku triedy z ITnetwork.

Ukážka pre PHP 5.3 a novšie:

<?php
namespace ItNetwork\Clanky\Modely;

class SpravceClanku
{
    // ...
}

ItNetwork je práve onen vendor, všetky jeho triedy musia byť v mennom priestore, ktorý začína názvom Vendor. Naopak knižnice, ktoré ITnetwork používa, sú v priestoroch ich Vendor, pretože sú to samostatné komponenty, ktoré nie sú súčasťou ITnetwork (Vendor ItNetwork).

Kód napísaný pre staršie PHP 5.2, ktoré nepodporovalo menné priestory, BY MAL používať podtržítkovou notáciu v názvoch tried, ktorá menné priestory nahradí:

<?php

class ItNetwork_Clanky_Modely_SpravceClanku
{
    // ...
}

Triedny konštanty, vlastnosti a metódy

Poďme sa pozrieť na to, ako by sme mali správne zapisovať triedny prvky. Keď budeme hovoriť o triedach, budeme myslieť aj rozhranie alebo Traits.

Konštanty

Triedny konštanty MUSÍ BYŤ deklarované veľkými písmenami as podtržníkmi.

Príklad zo štandardu:

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';
}

Vlastnosti

Od pomenovanie vlastností (atribútov) sa PSR-1 zámerne dištancuje. Je to z toho dôvodu, že by inak rozbila veľké množstvo starších projektov. Hlása, že by sme mali používať buď $ StudlyCaps, $ CamelCase alebo $ under_score. Avšak určite po vzore Javy nepoužívajte nič iné ako $ CamelCase.

Akúkoľvek konvencii zvolíte, MALI BY STE zostať konzistentná v rozumnom rozsahu. Tento rozsah môže byť na úrovni Vendor, balíka, triedy alebo metódy.

Zvyčajne sa jednej konvencie držíme v rozsahu kóde celého Vendor. Nemali by sme v ňom zavádzať niekoľko rôznych konvencií.

Metódy

Názvy metód MUSÍ byť deklarované v CamelCase ().

Tu je štandard veľmi striktný a to je dobre

Dúfam, že vás tutoriál zaujal a potrebné ste si opravili nejaký svoj projekt. Nabudúce, v lekcii Štandardy jazyka PHP - PSR-2 časť prvá , budeme pokračovať vo veľkom štýle a to u oveľa komplexnejšieho štandardu PSR-2.