Dodano: 24.04.2018
Dobre praktyki programistyczne
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
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 czy samego pozycjonowania strony), 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:
