Dobre praktyki programistyczne cz.1 – PSR

W dobie zwiększającego się zapotrzebowania na usługi programistyczne coraz więcej ludzi pragnie rozpocząć swoją przygodę z programowaniem. Często z języków Back-end owych wybierany jest język PHP ze względu na  niski próg wejścia i stosunkowo prostą składnię. Niestety ma to negatywny wpływ w środowisku programistów tegoż języka, ponieważ obniża się jakość kodu. I mowa tu nie tylko o odpowiednim wykorzystywaniu funkcji, obiektywności itp. Problem często zaczyna się już w samym wyglądzie kodu i jego składni. Tu pojawia się grupa zwana PHP Framework Interop Group (PHP-FIG). Postanowili oni wprowadzić standard programowania zwany PSR (PHP Standard Recommendation).

PSR jest to zbiór wytycznych co do programowania w języku PHP. Ustanowiono „dobre” praktyki programowania. Zbiór ten składa się w tej chwili z 18 zestawów wytycznych, jednak najczęściej używa się 10, a są to:
PSR-1: Basic Coding Standard
PSR-2: Coding Style Guide
PSR-3: Logger Interface
PSR-4: Autoloader
PSR-6: Caching Interface
PSR-7: HTTP message interfaces
PSR-11: Container interface
PSR-13: Link definition interfaces
PSR-15: HTTP Server Request Handlers
PSR-16: Common Interface for Caching Libraries

Nie ma sensu rozpisywać się nad każdym z nich. Link to ich opisów znajduje się tu. My jednak skupmy się na najpopularniejszym, czyli PSR-2. Dlaczego akurat ten? Ponieważ ten standard obsługuje i zaleca praktykować większość edytorów programistycznych takich jak: PHPStorm, Visual Studio Code. Jak sama nazwa podana powyżej mówi o stylu kodowania. W tej regule zdefiniowane są zalecenia dotyczące tab-ów, limitu znaków w jednym wierszu, otwierania i zamykania tagów czy nawet nazewnictwo metod, zmiennych czy obiektów. Ale jaki to ma wpływ na jakość kodu? Dobrze sformatowany kod z dobrym nazewnictwem czyta się dużo szybciej niżeli chaotycznie napisany kod ze zmiennymi o nazwie „x” czy „y”. A jak dobrze wiadomo kod, który piszemy jest tworzony nie dla maszyny (serwera, przeglądarki), ale dla drugiego człowieka (programisty). Tak więc starajmy się, aby inny programista pracujący nad naszym kodem nie musiał poświęcać kilku godzin na próbę zrozumienia tego, co „kolega” miał na myśli. Najlepiej sytuację przedstawi poniższy obrazek:

 

Dodano: 24 Kwiecień 2018