Standardy PSR-0,PSR-2,PSR-3, w jaki sposób pisać spójny i przejrzysty kod

1. PSR
czyli dobre praktyki programistyczne
Prepared for: PHPstock
Prepared by: Damian Michalski
Aurora Creation / PHP Magento Developer

2. Czym jest PSR?
PSR (PHP Standard Recommendation) - jest to zbiór wytycznych co do programowania w języku PHP.
Został on wprowadzony przez PHP Framework Interop Group (PHP-FIG)
Zbiór PSR składa się w tej chwili z 18 zestawów wytycznych.
Przedstawiamy 3 z nich:
● PSR-0: Autoloading Standard
● PSR-2: Coding Style Guide
● PSR-3: Logger Interface

3. ● Łatwość współpracy
● Niższy próg wejścia w ‘cudzy’ kod
● Dobrze sformatowany kod z dobrym
nazewnictwem czyta się dużo szybciej
niżeli chaotycznie napisany kod ze
zmiennymi o nazwie „x” czy „y”
● Kod tworzymy przede wszystkim dla
innych (programistów) a nie dla
maszyny
Zalety PSR
● Bullet 01
● Bullet 02
● Bullet 03
● ….

4. ● Magento: PSR-1 PSR-2
● Woocommerce: PSR?!
● Prestashop: PSR-1 PSR-
2
Jak do tego podchodzą inni?
● Bullet 01
● Bullet 02
● Bullet 03
● ….

5. PSR-0: Autoloading Standard

6. PSR-0 czyli stary standard zastąpiony przez PSR-4
— są to standardy dla automatycznego ładowania klas na podstawie struktury
katalogów w projekcie
W 2014 PSR-0 został oznaczony jako przestarzały.
PSR-4 jest teraz zalecany jako alternatywa.

7. PSR-0
● W pełni kwalifikowana przestrzeń nazw i klasa muszą mieć następującą strukturę
<Vendor Name>(<Namespace>)*<Class Name>
● Znak _ ma specjalne znaczenie w obszarze nazw.
● W pełni kwalifikowana przestrzeń nazw i klasa są sufiksami .php podczas ładowania z systemu plików.

8. Dlaczego PSR-4 wyparło PSR-0?
PSR-0 działa jedynie w przypadku, gdyby na świecie istniały jedynie klasy PHP.
Jednak, gdy do projektu dodajemy elementy spoza PHP, powstaje problem:
w jaki sposób umieścić je w projekcie?
Gdzie je zmieścić?
Projekt może mieć podkatalogi
np. doc, examples, license, css, js, img, src na kod PHP.
Wtedy należy umieścić podkatalog src w nazwie klasy.
Powstaje wówczas np. klasa:
userProjektPierwszysrcModułPierwszyKlasa
Projekt
- dokumentacje,
- przykłady,
- testy jednostkowe,
- style,
- grafiki
- inne

9. Wady PSR-0 oraz dlaczego lepsze jest PSR-4.
Najważniejsza zmiana to sposób traktowania ścieżki do projektu. Tym razem zamiast jednej, możemy mieć wiele ścieżek,
każda zdefiniowana dla jakiegoś prefiksu nazwy klasy.
Przykłady:
userModulPierwszy => /vendor/user/ModulA/src/php
userModulDrugi => /vendor/user/ModulB/classes/
Co więcej, możemy przypisać kilka ścieżek do jednego prefiksu:
userModulPierwszy => /vendor/user/ModulA/src/php
userModulPierwszy => /vendor/user/PoprawkiDoModuluA/php/classes
Autoloader gdy już dopasuje prefiks nazwy do jakiejś ścieżki traktuje resztę nazwy w
klasyczny sposób – rozbija na podkatalogi i szuka pliku php.

10. PSR-4
● Termin „klasa” odnosi się do klas, interfejsów, cech i innych podobnych struktur.
Np.:
<NamespaceName>(<SubNamespaceNames>)*<ClassName>
● Implementacje autoloadera NIE MOGĄ zgłaszać wyjątków,
NIE MOGĄ zgłaszać błędów o dowolnym poziomie
i NIE POWINNY zwracać wartości.

11. PSR-2: Coding Style Guide

12. PSR-2 — styl/standard kodowania w PHP (zbiór zasad w który wchodzi PSR-1)
● Kod MUSI postępować zgodnie z „przewodnikiem po stylu kodowania” PSR [ PSR-1 ].
● NIE MOŻE istnieć twardy limit długości linii; miękki limit MUSI wynosić 120 znaków; wiersze MUSZĄ mieć 80 znaków lub mniej.
● Kod MUSI używać 4 spacji do wcięcia, a nie tabulacji.
● Po namespace deklaracji MUSI znajdować się jedna pusta linia, a za blokiem use deklaracji MUSI znajdować się jedna pusta
linia.
● Klamry otwierające dla klas MUSZĄ przejść do następnej linii, a klamry otwierające MUSZĄ przejść do następnej linii po ciele.
● Nawiasy otwierające dla metod MUSZĄ przejść do następnej linii, a nawiasy zamykające MUSZĄ przejść do następnej linii po
ciele.
● Nawiasy otwierające dla struktur kontrolnych MUSZĄ iść na tej samej linii, a nawiasy zamykające MUSZĄ przejść na następną
linię za ciałem.
● Nawiasy otwierające dla struktur kontrolnych NIE MOGĄ mieć po sobie spacji, a nawiasy zamykające dla struktur kontrolnych
NIE MOGĄ mieć wcześniej spacji.

13. PSR-1 — styl/standard kodowania w PHP
● Pliki muszą używać tylko <?php i <?= tagi.
● Pliki powinny albo zadeklarować symbole (klasy, funkcje, stałe, etc.) lub powodować skutki uboczne
(np generować wyjście, zmień ustawienia .ini, itp), ale nie należy robić jedno i drugie.
● Przestrzenie nazw i klasy MUSZĄ być zgodne z PSR „autoloadingu”: [ PSR-0 , PSR-4 ].
● Stałe klas MUSZĄ być deklarowane wielkimi literami z separatorami podkreślenia.

14. PSR-2 — styl/standard kodowania w PHP (zbiór zasad w który wchodzi PSR-1),
● Kod MUSI postępować zgodnie z „przewodnikiem po stylu kodowania” PSR [ PSR-1 ].
● Kod MUSI używać 4 spacji do wcięcia, a nie tabulacji.
● NIE MOŻE istnieć twardy limit długości linii; miękki limit MUSI wynosić 120 znaków; wiersze MUSZĄ mieć 80 znaków lub mniej.
● Po namespace deklaracji MUSI znajdować się jedna pusta linia, a za blokiem use deklaracji MUSI znajdować się jedna pusta linia
.
● Klamry otwierające dla klas MUSZĄ przejść do następnej linii, a klamry otwierające MUSZĄ przejść do następnej linii po ciele.
● Nawiasy otwierające dla metod MUSZĄ przejść do następnej linii, a nawiasy zamykające MUSZĄ przejść do następnej linii po
ciele.
● Nawiasy otwierające dla struktur kontrolnych MUSZĄ iść na tej samej linii, a nawiasy zamykające MUSZĄ przejść na następną
linię za ciałem.
● Nawiasy otwierające dla struktur kontrolnych NIE MOGĄ mieć po sobie spacji, a nawiasy zamykające dla struktur kontrolnych NIE
MOGĄ mieć wcześniej spacji.

15. PSR-2 — styl/standard kodowania w PHP (zbiór zasad w który wchodzi PSR-1),

16. PSR-3: Logger Interface
Jest osiem głównych poziomów logów
const DEBUG = 'debug';
i osiem odpowiadających im metod w klasie (interfejs):
public function debug ($message, array $context = array());

17. W PSR-3 znajduje się osiem głównych poziomów logów (w tej kolejności):
● emergency - system jest bezużyteczny (unusable),
● alert - należy podjąć jakąś akcje np.: niedostępna baza danych, strona przestała działać, …,
● critical - przypadek krytyczny; np.: wystąpił wyjątek (programista nawalił), niedostępny komponent w kodzie,
● error - błąd podczas wykonywania ale nie zmuszający do natychmiastowej interwencji, jednak ważne aby był
zalogowany,
● warning - wyjątek po części akceptowalny (nie błąd), np.: używanie przestarzałego API, lub niepożądane użycie API,
● notice - normalne zdarzenie, które warto zalogować (ale ważniejsze od zdarzenia info),
● info - zdarzenie informacyjne rozszerzające logowane informacje, np.: User się zalogował, logi z SQL,
● debug - informacje szczegółowe, jeszcze bardziej techniczne i nawet sugerujące optymalizację lub podające zużycie
zasobów lub czasu,
● metoda log() - jest to ostatnia, dziewiąta metoda działa tak samo jak poprzednie tylko jako pierwszy argument
przyjmuje poziom logowania. W praktyce to ta metoda przeważnie zapisuje logi. Pozostałe przeważnie tylko ją
wywołują.

18. Potrzebujesz wiedzieć więcej?
Napisz do nas!
biuro@auroracreation.pl