W pracy nad większymi projektami, ale też nad małymi aplikacjami, mamy często do czynienia z kodem pisanym przez inne osoby (wliczając w to siebie sprzed paru miesięcy). W takich przypadkach bardzo ważna jest możliwość szybkiego zrozumienia działania kodu, który musimy zmienić lub rozbudować.
Patrząc na fragment kodu musimy szybko i jednoznacznie określić jego funkcję. Chociaż gramatyka języka się nie zmienia, sposób w jaki kod jest napisany może mieć duży wpływ na szybkość jego poznania. Jeśli znamy styl, w jakim kod jest napisany, o wiele łatwiej jest nam skoncentrować się na badaniu jego funkcji, a nie na rozszyfrowywaniu sposobu jego zapisu. Dzięki ujednoliceniu formatu możemy o wiele szybciej zacząć nasze modyfikacje, a jeśli nasze zmiany też będą przestrzegać ujednoliconych zasad, inne osoby pracujące w przyszłości będą miały ułatwione zadanie.
Ustalenie sposobu zapisu może być dość trudne, gdy nad aplikacją pracuje wiele programistów, a nie ma wśród nich osoby z wystarczającym autorytetem. W takim wypadku najlepiej jest zebrać wszystkich (lub tylko ich przedstawicieli, jeśli byłoby ich za dużo) i postarać się znaleźć wszelkie „za” i „przeciw” poszczególnych elementów stylu zapisu i wybrać najlpsze z nich. Dyskusja taka powinna zakończyć się stworzeniem wytycznych, które będą stosowane przez cały zespół.
Poniżej przedstawiam propozycję formatowania kodu, którą uważam za najbardziej przejrzystą i praktyczną. Jest ona wzrorowana na różnych praktykach: GNU, C, PEAR, Zend Framework, z modyfikacjami opracowanymi przez zespoły, z którymi pracuję albo pracowałem w przeszłości. Większość z tych propozycji świetnie sprawdza się w praktyce i ułatwia pracę wielu osób nad tym samym kodem.
Ogólne zasady
Przy dołączaniu plików zawsze używaj require i include. Zawsze staraj sie używać pełnych ścieżek do plików. To oszczędza serwerowi czas na zbadanie ścieżki dostępu w przypadku, gdy podamy tylko samą nazwę pliku. Polecenia require_once i include_once powoduja wykonanie przez serwer dodatkowych funkcji na plikach i sprawdzenie, czy nie zostały one wcześniej już załadowane. Powinienieś znać swój kod i wiedzieć, które pliki powinny dołączać jakie biblioteki. Nie dołączaj też innych plików w deklaracjach klas.
Nazewnictwo
W nazwach plików, klas, metod i zmiennych używaj camelCaps. Wyjątkiem jest nazywanie define’s, które powinny być pisane wielkimi literami. Nazwy plików powinny odzwierciedlać ich zawartość. W przypadku plików z deklaracjami klas używaj formatu PEAR: Aplikacja_Biblioteka_Klasa.php. To ułatwi stosowanie funkcji __autoload() to ładowania potrzebnych plików. Nie używaj __ (podwójne podkreślenie) w nazwie metod i funkcji. Nazwy takie powinny być wykorzystywane tylko przez sam PHP (jest to oczywiście zalecenie: tworzenie metod z takich przedrostkiem nie jest zakazane, lecz niektóre nazwy są zarezerwowane przez PHP, np. __autoload, __get, __sleep, itd.
SQL
Nie stosuj gwiazdki (*) w zapytaniach. To powoduje większe obciążenia serwera bazy danych, który najpierw musi pobrać listę kolumn w tabeli. Poza tym możesz nie potrzebować danych z każdej kolumny. Tym sposobem zaoszczędzisz też trochę czasu. Polecenia SQL pisz wielkimi literami i odpowiednio wyjustuj zapytanie, aby było łatwe do odczytania nie tylko przez serwer, ale też i Ciebie.
Kilka innych stron opisujących sposoby formatowania kodu:
http://pear.php.net/package/PHP_CodeSniffer/
https://trac.cakephp.org/wiki/Developement/CodingStandards
http://www.procata.com/blog/archives/2004/09/24/php-coding-standards/
http://ez.no/ezpublish/documentation/development/standards/php
http://framework.zend.com/manual/en/coding-standard.html
http://pear.php.net/manual/en/standards.php
http://mikenaberezny.com/talks/zendcon06/php_development_best_practices.pdf – slajdy z prezentacji Mike’a Nabereznego
Każdy powinien wypracować swój styl i się go trzymać. Nie można obiektywnie stwierdzić, który styl jest lepszy, a który gorszy. To zależy od preferencji programisty. Ważne jest natomiast, aby ujednolicić standard w całej aplikacji, co pozwoli nam na szybszą analizę kodu i szybsze dotarcie do fragmentów, które wymagają zmian.