PHP 5. Narzędzia dla ekspertów [PDF]

Zitiervorschau

Spis treĂci O autorze

9

O recenzentach

11

Przedmowa

13

O czym jest ta ksiÈĝka? Co jest potrzebne, aby skorzystaÊ z ksiÈĝki? Dla kogo jest ta ksiÈĝka? Konwencje Uwagi Czytelników Przykïadowy kod

Rozdziaï 1. Standardy i styl pisania kodu Co uwzglÚdniÊ przy tworzeniu standardów? Zalety Wady Standard pisania kodu PHP Formatowanie Konwencje nazewnicze Metodologia Weryfikacja zgodnoĂci ze standardami pisania kodu Automatyczna kontrola zgodnoĂci za pomocÈ narzÚdzia PHP_CodeSniffer Podsumowanie

Rozdziaï 2. Dokumentowanie za pomocÈ narzÚdzia phpDocumentor Dokumentacja w treĂci kodu Poziomy szczegóïowoĂci Wprowadzenie do programu phpDocumentor Instalacja programu phpDocumentor Bloki DocBlock Szablony DocBlock

13 14 14 15 15 16

17 17 18 19 19 20 25 29 35 35 46

49 50 51 52 52 54 55

Spis treĞci

Samouczki Dokumentowanie projektu Opcje programu phpDocumentor Katalog tagów Tagi stosowane w PHP4 Tagi uĝytkownika Podsumowanie

Rozdziaï 3. Eclipse — zintegrowane Ărodowisko programistyczne Dlaczego Eclipse? Wprowadzenie do PDT Instalacja Eclipse Wymagania Wybór pakietu Dodawanie pluginu PDT Podstawowe pojÚcia zwiÈzane z Eclipse Przestrzeñ robocza (Workspace) Widoki (Views) Perspektywy Przykïadowy projekt PDT MoĝliwoĂci funkcjonalne pluginu PDT Edytor Inspekcja Debugowanie Preferencje PDT Inne moĝliwoĂci funkcjonalne Pluginy Eclipse Zend Studio dla Eclipse Wsparcie Refaktoring Generowanie kodu Testowanie za pomocÈ PHPUnit Obsïuga programu phpDocumentor Integracja ze szkieletem Zend Framework Integracja z serwerem Zend Podsumowanie

Rozdziaï 4. ZarzÈdzanie kodem ěródïowym i wersjami Typowe przypadki uĝycia Krótka historia kontroli kodu ěródïowego CVS Wprowadzenie do Subversion Instalacja klienta Konfiguracja serwera PojÚcia zwiÈzane z Subversion Lista poleceñ Subversion Tworzenie projektu Subversion

4

56 59 74 78 94 94 95

97 98 100 100 100 102 102 104 104 105 107 108 111 111 115 117 120 127 128 129 131 131 131 131 132 133 133 133

135 135 136 139 141 141 142 143 147 157

Spis treĞci

Sposób pracy z systemem kontroli wersji Bliĝsze spojrzenie na repozytorium OdgaïÚzienia i scalanie Aplikacje klienckie Konwencje i najlepsze praktyki przy pracy z Subversion Przystosowywanie Subversion do wïasnych potrzeb Powiadamianie programistów o zatwierdzonych plikach za pomocÈ skryptu post-commit Podsumowanie

Rozdziaï 5. Debugowanie Pierwsza linia obrony — kontrola skïadni Dzienniki Opcje konfiguracyjne Dostosowywanie opcji konfiguracyjnych i panowanie nad nimi — PhpIni WyĂwietlanie informacji diagnostycznych Funkcje „Magiczne” staïe Tworzenie wïasnej klasy diagnostycznej Wprowadzenie do Xdebug Instalacja Xdebug Konfiguracja Xdebug Natychmiastowe korzyĂci Zdalne debugowanie Podsumowanie

Rozdziaï 6. Szkielety aplikacji PHP Pisanie wïasnego szkieletu Ocena i wybór szkieletów SpoïecznoĂÊ i akceptacja MoĝliwoĂci funkcjonalne Dokumentacja JakoĂÊ kodu Stosowanie i zgodnoĂÊ ze standardami pisania kodu Dopasowanie do projektu ’atwoĂÊ w nauce i adaptacji DostÚpnoĂÊ kodu ěródïowego ZnajomoĂÊ szkieletu Ich zasady Popularne szkielety aplikacji PHP Zend CakePHP CodeIgniter Symfony Yii

164 169 171 177 183 184 187 187

189 189 191 192 194 201 201 205 205 221 221 224 225 228 235

237 237 238 239 239 240 240 241 241 242 242 243 243 243 244 244 245 245 246

5

Spis treĞci

Aplikacja w szkielecie Zend Framework Lista cech i funkcji KrÚgosïup aplikacji Usprawnienia Podsumowanie

Rozdziaï 7. Testowanie Metody testowania Czarna skrzynka Biaïa skrzynka Szara skrzynka Typy testowania Testowanie jednostkowe Testowanie integracyjne Testowanie regresyjne Testowanie systemowe Testy akceptacji uĝytkowników Wprowadzenie do PHPUnit Instalacja PHPUnit Przeszukiwanie ciÈgu tekstowego (przykïadowy projekt) Analiza pokrycia kodu Podklasy klasy TestCase Podsumowanie

Rozdziaï 8. Wdraĝanie aplikacji Cele i wymagania Wdraĝanie aplikacji Wymeldowywanie plików i wysyïanie ich na serwer WyĂwietlanie informacji o niedostÚpnoĂci serwisu Aktualizacja i instalacja plików Aktualizacja schematu i zawartoĂci bazy danych Rotacja plików dziennika i aktualizacja dowiÈzañ symbolicznych Weryfikacja wdroĝonej aplikacji Automatyzacja procesu wdroĝenia Phing Podstawowa skïadnia i struktura pliku Typy Wdraĝanie serwisu Podsumowanie

Rozdziaï 9. Projektowanie aplikacji za pomocÈ jÚzyka UML Metamodel i notacja a nasze podejĂcie do UML Poziom szczegóïowoĂci i przeznaczenie NarzÚdzia jedno- i dwukierunkowe Podstawowe typy diagramów UML Diagramy

6

247 247 248 253 272

273 273 274 274 275 276 276 277 277 278 278 279 279 281 306 307 308

309 309 311 312 313 313 314 314 315 315 315 317 321 322 339

341 342 343 344 345 346

Spis treĞci

Diagramy klas Diagramy sekwencji Przypadki uĝycia Podsumowanie

Rozdziaï 10. CiÈgïa integracja Systemy satelitarne Kontrola wersji — Subversion Testowanie — PHPUnit Automatyzacja — Phing Styl pisania kodu — PHP_CodeSniffer Dokumentowanie — PhpDocumentor Analiza pokrycia kodu — Xdebug Przygotowanie Ărodowiska Czy potrzebujÚ dedykowanego serwera CI? Czy potrzebujÚ narzÚdzia CI? NarzÚdzia CI XINC phpUnderControl CiÈgïa integracja z phpUnderControl Instalacja Konfiguracja CruiseControl PrzeglÈd procesu i komponentów ciÈgïej integracji Podsumowanie

Skorowidz

347 359 364 368

369 371 371 372 373 374 375 375 376 376 376 377 377 377 378 378 382 382 404

405

7

Spis treĞci

8

O autorze Dirk Merkel od wielu lat pisze oprogramowanie w róĝnych jÚzykach, w tym PHP Java, Perl i Ruby. Specjalizuje siÚ w technologiach internetowych i ma ponad 10 lat praktyki w programowaniu w PHP. Jego doĂwiadczenie obejmuje uczestnictwo we wszystkich etapach cyklu produkcji oprogramowania i zarzÈdzanie kilkoma zespoïami programistów pracujÈcych nad duĝymi projektami. Obecnie pracuje jako konsultant w firmie Waferthin Web Works LLC (http://www.waferthin.com) i moĝna siÚ z nim skontaktowaÊ pod adresem [email protected]. Jest takĝe dyrektorem technicznym w firmie VivianTech Inc. z San Diego, oferujÈcej rozwiÈzania informatyczne. Napisaï kilka artykuïów o tworzeniu i zabezpieczaniu oprogramowania. PHP 5. NarzÚdzia dla ekspertów to jego pierwsza ksiÈĝka. Dirk Merkel mieszka w San Diego z ĝonÈ i dwoma wspaniaïymi córkami. PragnÚ podziÚkowaÊ swojej rodzinie (bliĝszej i dalszej) — szczególnie moim rodzicom i siostrom, mojej kochanej ĝonie Ranii i wspaniaïym córkom, Nadii i Yasmin.

PHP 5. NarzĊdzia dla ekspertów

10

O recenzentach Andrew J. Peterson mieszka z ĝonÈ i trzema córkami w San Francisco. Ma dwudziestoletnie doĂwiadczenie w tworzeniu oprogramowania konsumenckiego, oprogramowania dla duĝych i maïych firm oraz organizacji poĝytku publicznego. Jego wiedza obejmuje wszystkie fazy cyklu produkcji oprogramowania, inĝynieriÚ oprogramowania, metodologie, architekturÚ i uĝytecznoĂÊ. Ma doĂwiadczenie w wielu róĝnych dziedzinach zastosowania rozwiÈzañ informatycznych. W sferze konsumenckiej nadzorowaï pracÚ zespoïu, który stworzyï doskonale sprzedajÈcy siÚ program SoundEdit16. Pracowaï nad róĝnorodnym oprogramowaniem dla firm, w tym dla czoïowego dostawcy rozwiÈzañ informatycznych dla terminali kontenerowych, portów przeïadunkowych oraz centrów dystrybucyjnych. Na przestrzeni ostatnich dziesiÚciu lat zaadaptowaï te doĂwiadczenia na potrzeby oprogramowania internetowego. Stworzyï wiele aplikacji internetowych, w tym aplikacje dla organizacji poĝytku publicznego, portale i wyszukiwarki spoïecznoĂciowe, aplikacje dla branĝy farmaceutycznej i spoïecznoĂciowe platformy handlowe. Ukoñczyï wiele projektów pisanych w róĝnych jÚzykach, w tym Java, Ruby, C++ i Perl. We wczesnym stadium rozwoju sieci WWW napisaï poradnik, który pomagaï podïÈczyÊ siÚ do niej uĝytkownikom komputerów Macintosh. Ostatnio byï recenzentem ksiÈĝki PHP and Scriptaculous Web Application Interfaces (Packt Publishing). Chciaïbym podziÚkowaÊ swojej ĝonie za to, ĝe jest ěródïem radoĂci. Deepak Vohra jest konsultantem i wïaĂcicielem firmy programistycznej NuBean.com. Posiada certyfikaty Sun Certified Java Programmer oraz Web Component Developer; od ponad piÚciu lat specjalizuje siÚ w XML oraz programowaniu w jÚzykach Java i J2EE. Jest wspóïautorem wydanej przez Apress ksiÈĝki Pro XML Development with Java Technology, recenzentem WebLogic: The Definitive Guide (O’Reilly), recenzentem technicznym Ruby Programming for Absolute Beginner (Course Technology PTR) oraz redaktorem technicznym Prototype and Scriptaculous in Action (Manning Publications). Napisaï ksiÈĝki JDBC 4.0 and Oracle JDeveloper for J2EE Development i Processing XML Documents with Oracle JDeveloper 11g, wydane przez Packt Publishing.

PHP 5. NarzĊdzia dla ekspertów

12

Przedmowa DziÚki tej ksiÈĝce programiĂci PHP mogÈ zwiÚkszyÊ swoje umiejÚtnoĂci. Przedstawia ona metodykÚ i narzÚdzia niezbÚdne do pisania wydajnego i ïatwego w utrzymaniu kodu. Uczy, jak prowadziÊ testy jednostkowe, jak trzymaÊ siÚ standardów pisania kodu, jak automatyzowaÊ wdroĝenia i interaktywnie wyszukiwaÊ bïÚdy przy wykorzystaniu narzÚdzi stworzonych w tym celu dla programistów PHP. DziÚki lekturze tej ksiÈĝki sprawisz, ĝe Twój kod bÚdzie wydajny, ïatwiejszy w utrzymaniu i bÚdzie siÚ sam dokumentowaï.

O czym jest ta ksiÈĝka? W rozdziale 1., „Standardy i styl pisania kodu”, omówiono, jak definiowaÊ standardy pisania kodu, które pasujÈ do konkretnego procesu produkcji oprogramowania, i jak wymuszaÊ trzymanie siÚ standardów za pomocÈ narzÚdzia PHP_CodeSniffer. W rozdziale 2., „Dokumentowanie za pomocÈ narzÚdzia phpDocumentor”, objaĂniono, jak prawidïowo dokumentowaÊ kod za pomocÈ narzÚdzia phpDocumentor i jak generowaÊ odpowiednio sformatowanÈ dokumentacjÚ programistycznÈ. W rozdziale 3., „Eclipse — zintegrowane Ărodowisko programistyczne”, przedstawiono, jak zainstalowaÊ darmowy plugin PDT dla Eclipse, jak go dostosowaÊ i jak korzystaÊ z niego, aby stworzyÊ Ărodowisko programistyczne PHP o ogromnych moĝliwoĂciach. W rozdziale 4., „ZarzÈdzanie kodem ěródïowym i wersjami”, omówiono narzÚdzie Subversion, udostÚpniajÈce zespoïom programistów rozproszonÈ kontrolÚ wersji. Pokazano teĝ, jak rozszerzyÊ funkcjonalnoĂÊ Subversion skryptami PHP. W rozdziale 5., „Debugowanie”, wyjaĂniono, jak napisaÊ wïasnÈ, uniwersalnÈ bibliotekÚ wspomagajÈcÈ debugowanie oraz jak opanowaÊ debugowanie interaktywne za pomocÈ narzÚdzia Xdebug.

PHP 5. NarzĊdzia dla ekspertów

W rozdziale 6., „Szkielety aplikacji PHP”, opisano, jak analizowaÊ, porównywaÊ i wybieraÊ szkielety, które pasujÈ do projektu i stylu tworzenia oprogramowania. Omówiono teĝ najczÚĂciej stosowane moduïy szkieletu Zend Framework. W rozdziale 7., „Testowanie”, omówione zostaïy metody i typy testowania, testowanie jednostkowe, tworzenie wszechstronnych pakietów testujÈcych za pomocÈ narzÚdzia PHPUnit oraz metodyka tworzenia oprogramowania bazujÈca na testowaniu. W rozdziale 8., „Wdraĝanie aplikacji”, opisano wytyczne dla zautomatyzowanego i odwracalnego wdraĝania aplikacji, metody automatyzacji aktualizacji oprogramowania i wdraĝanie aplikacji przy uĝyciu narzÚdzia Phing. W rozdziale 9., „Projektowanie aplikacji za pomocÈ jÚzyka UML”, zawarto wprowadzenie do UML, omówiono diagramy klas, diagramy sekwencji i przypadki uĝycia. W rozdziale 10., „CiÈgïa integracja”, opisano, jak za pomocÈ CI utrzymywaÊ niskie koszty i oszczÚdzaÊ czas poprzez wyszukiwanie bïÚdów i konfliktów w projektach na wczesnym etapie produkcji.

Co jest potrzebne, aby skorzystaÊ z ksiÈĝki? Aby móc analizowaÊ przykïady, potrzebny jest dostÚp do zainstalowanej, dziaïajÈcej wersji PHP5. W niektórych rozdziaïach wykorzystano narzÚdzia uruchamiane z wiersza poleceñ, takie jak pear czy pecl, stanowiÈce czÚĂÊ standardowej dystrybucji PHP. Aby uzyskaÊ maksymalnÈ kompatybilnoĂÊ PHP z przykïadami kodu, zalecane sÈ wersje PHP od 5.2.x w górÚ. PHP moĝna pobraÊ ze strony php.net: http://www.php.net/downloads.php. Niniejsza ksiÈĝka i zawarty w niej kod sÈ oparte na Ărodowisku OS X, ale wszelkie odmiany systemów Windows i Linux powinny byÊ zgodne. Przydatne bÚdÈ umiejÚtnoĂÊ posïugiwania siÚ wierszem poleceñ w danym systemie oraz podrÚczny edytor tekstu do eksperymentowania z przykïadami.

Dla kogo jest ta ksiÈĝka? KsiÈĝka ta zostaïa napisana z myĂlÈ zarówno o zawodowych programistach, którzy zapoznajÈ siÚ dopiero z PHP, jak i o doĂwiadczonych programistach PHP, którzy chcÈ zwiÚkszyÊ swoje umiejÚtnoĂci, poznajÈc profesjonalne narzÚdzia i techniki.

14

Przedmowa

Konwencje W ksiÈĝce wystÚpuje kilka stylów tekstu, które pomagajÈ rozróĝniÊ pewne typy informacji. Oto kilka przykïadów zastosowania tych stylów wraz z opisami ich znaczenia. Fragmenty kodu w treĂci zdania sÈ wyróĝniane nastÚpujÈco: „Moĝemy doïÈczyÊ inne konteksty za pomocÈ dyrektywy include”. Bloki kodu wyglÈdajÈ tak:



Jeĝeli autor chce zwróciÊ uwagÚ Czytelnika na okreĂlony fragment kodu, fragment ten bÚdzie pogrubiony:



Wszelkie wpisywane polecenia i generowane komunikaty w wierszu poleceñ wyglÈdajÈ nastÚpujÈco: $ phing upgrade-db

Nowe pojÚcia i waĝne sïowa bÚdÈ pogrubiane. Sïowa, które pojawiajÈ siÚ na ekranie, w menu programów lub oknach dialogowych, bÚdÈ wyróĝniane w tekĂcie nastÚpujÈco: „klikniÚcie przycisku Next przenosi nas do nastÚpnego ekranu”. Wskazówki, sugestie i waĝne informacje pojawiaÊ siÚ bÚdÈ w takich ramkach.

Uwagi Czytelników Wszelkie uwagi Czytelników sÈ zawsze mile widziane. ChÚtnie poznamy Wasze opinie o tej ksiÈĝce, dowiemy siÚ, co siÚ Wam podobaïo, a co nie. Opinie Czytelników pomagajÈ nam tworzyÊ ksiÈĝki najpeïniej opisujÈce dany temat. Prosimy o wyraĝanie opinii i uwag za pomocÈ formularza na stronie http://helion.pl/user/opinie/.

15

PHP 5. NarzĊdzia dla ekspertów

Jeĝeli potrzebujesz jakiejĂ ksiÈĝki i chciaïbyĂ, abyĂmy jÈ wydali, napisz do nas, korzystajÈc z formularza jakie ksiÈĝki na stronie http://www.helion.pl. Jeĝeli jesteĂ ekspertem w jakiejĂ dziedzinie i chcesz napisaÊ ksiÈĝkÚ, zajrzyj na stronÚ http://helion.pl/zostanautorem.

Przykïadowy kod Przykïadowy kod omówiony w ksiÈĝce moĝna pobraÊ pod adresem ftp://ftp.helion.pl/przyklady/ php5ne.zip. W plikach zawarte zostaïy instrukcje ich uĝycia.

16

1 Standardy i styl pisania kodu Wypracowanie wïasnego stylu pisania kodu zajmuje trochÚ czasu, a sam styl czÚsto odzwierciedla osobowoĂÊ programisty. Dlatego teĝ próby nakïonienia czïonków zespoïu do trzymania siÚ okreĂlonego stylu czÚsto spotykajÈ siÚ z oporami. Jednak wïaĂnie temu poĂwiÚcony bÚdzie niniejszy rozdziaï. Poznasz korzyĂci pïynÈce ze standaryzacji stylu pisania kodu. Przy okazji dopracujesz wïasny styl i dowiesz siÚ, jak automatycznie wymuszaÊ dowolnie przyjÚtÈ standaryzacjÚ za pomocÈ narzÚdzia PHP_CodeSniffer. Mam nadziejÚ, ĝe po lekturze tego rozdziaïu bÚdziesz potrafiï przeanalizowaÊ styl pisania kodu — wïasny i swoich wspóïpracowników — i wprowadziÊ w nim zmiany, które dadzÈ korzyĂci w postaci czytelniejszego i ïatwiejszego w utrzymaniu kodu.

Co uwzglÚdniÊ przy tworzeniu standardów? Skoro czytasz tÚ ksiÈĝkÚ, bardzo moĝliwe, ĝe masz juĝ kilkuletnie doĂwiadczenie w programowaniu. Nawet jeĝeli programowaïeĂ w innym jÚzyku niĝ PHP, z pewnoĂciÈ zdÈĝyïeĂ wypracowaÊ sobie wïasny styl pisania kodu. Jak moĝna przypuszczaÊ, wybraïeĂ lub wypracowaïeĂ styl, który wydaje Ci siÚ najbardziej sensowny, najczytelniejszy i którego ïatwo siÚ trzymaÊ. To, ĝe czytasz tÚ ksiÈĝkÚ, oznacza równieĝ, ĝe pragniesz poprawiÊ swoje umiejÚtnoĂci w zakresie PHP, stÈd teĝ zakïadam, ĝe jesteĂ skïonny zmieniÊ swój styl pisania kodu albo przynajmniej go skorygowaÊ. Na poczÈtek chciaïbym CiÚ przekonaÊ, ĝe warto. Nawet jeĝeli piszesz kod samemu i nie spodziewasz siÚ, ĝe inni programiĂci bÚdÈ go przeglÈdaÊ lub pracowaÊ na nim, prawdopodobnie chcesz trzymaÊ siÚ pewnych wïasnych standardów jego pisania. Bardzo moĝliwe, ĝe nieĂwiadomie juĝ to robisz. Na przykïad kaĝdy programista

PHP 5. NarzĊdzia dla ekspertów

decyduje siÚ kiedyĂ, czy otwieraÊ nawias klamrowy w tym samym wierszu, w którym wystÚpuje instrukcja if, czy w nastÚpnym. NajczÚĂciej wówczas przyzwyczaja siÚ do takiego czy innego stylu. Akurat wielokrotnie zdarzaïo mi siÚ wracaÊ po latach do kodu, który sam napisaïem i z którym w miÚdzyczasie nie miaïem stycznoĂci. Za kaĝdym razem mogïem okreĂliÊ, na ile ugruntowany byï mój styl pisania kodu. Im bardziej konsekwentny styl, tym ïatwiej powracaÊ do starego kodu i pojmowaÊ szczegóïy wïasnego rozumowania. MyĂlÚ, ĝe wszyscy po pewnym okresie braku stycznoĂci z wïasnym kodem mamy problemy z jego zrozumieniem. Wyobraěmy sobie teraz, o ile juĝ nie byliĂmy w takiej sytuacji, przejÚcie duĝego projektu po innym programiĂcie i przyzwyczajanie siÚ do jego nawyków i osobliwoĂci. WïaĂnie w takich sytuacjach korzyĂci przynosi ustalenie wspólnego standardu pisania kodu. Jeĝeli wszyscy programiĂci pracujÈcy nad jednym projektem uzgodniÈ taki standard, wspóïpraca i zrozumienie tego, co robiÈ inni, stajÈ siÚ o wiele ïatwiejsze. I nie chodzi mi o takie kwestie jak miejsce, w którym otwieramy klamrÚ, lecz bardziej o umiejscowienie klas i bibliotek, nazewnictwo metod i atrybutów oraz dokumentowanie w treĂci kodu. Przeanalizujmy wybrane zalety i wady dysponowania formalnie zdefiniowanymi standardami pisania kodu, poczynajÈc od zalet.

Zalety Zrozumienie kodu stanie siÚ ïatwiejsze. Niezaleĝnie od tego, czy czytamy wïasny kod, czy kod innego czïonka zespoïu, jego analizowanie i zrozumienie bÚdzie trwaïo krócej. Odnosi siÚ to nie tylko do „starych” uczestników projektu, ale i do programistów, którzy dopiero wdraĝajÈ siÚ w pracÚ w danym zespole albo w ogóle w jÚzyk PHP. Nie muszÈc ogarniaÊ róĝnych stylów i konwencji, mogÈ oni szybciej opanowaÊ kod i przy okazji od poczÈtku przyswoiÊ sobie ogólnie uzgodniony styl. Oprogramowanie jest obecnie czÚsto projektowane, pisane, testowane i uĝywane w sposób rozproszony. Czïonkowie zespoïu mogÈ pracowaÊ w dowolnych miejscach na Ăwiecie. Wspóïczesne narzÚdzia komunikacji zrewolucjonizowaïy reguïy opisujÈce, gdzie i jak tworzyÊ zespoïy programistów. Wystarczy spojrzeÊ na niektóre udane projekty open source, z których wiele nie ma ĝadnej fizycznej „siedziby”. Weěmy takie projekty, jak Apache Software Foundation czy Zend Framework — obydwa osiÈgnÚïy wielki sukces w rezultacie pracy wielu uczestników rozproszonych po caïym Ăwiecie. Tego typu projekty to Ăwietlane przykïady osiÈgania korzyĂci z przyjÚcia pewnych wspólnych standardów pisania kodu. Jestem skïonny twierdziÊ, ĝe dobre standardy pisania kodu nie poprawiajÈ wyïÈcznie stylu, ale równieĝ jakoĂÊ i spójnoĂÊ kodu. Na przykïad jednorodny sposób walidacji parametrów przyjmowanych przez metody z pewnoĂciÈ przyczyni siÚ do stworzenia spójniejszej bazy kodowej.

18

Rozdziaá 1. • Standardy i styl pisania kodu

Wady ProgramiĂci majÈ tendencjÚ do ignorowania standardów pisania kodu. Trzymanie siÚ standardów wymaga od wszystkich zmiany nawyków, czasami bardziej, czasami mniej. Musi byÊ ktoĂ, kto weěmie na siebie odpowiedzialnoĂÊ za utrzymywanie standardów, bo ich adaptacja nie nastÈpi samoistnie. JeĂli programiĂci majÈ zbyt utrwalone nawyki lub reagujÈ negatywnie, gdy sÈ proszeni o ich zmianÚ, ryzykujemy utratÚ ich zaufania. Najlepiej wiÚc zaangaĝowaÊ wszystkich w opracowywanie standardów. Po zainwestowaniu wïasnego czasu i umiejÚtnoĂci w tworzenie standardów uczestnicy projektu bÚdÈ bardziej skïonni trzymaÊ siÚ uzgodnionych wspólnie reguï. Istnieje wiele mitów zwiÈzanych ze standardami pisania kodu. Po pierwsze, wiele osób sÈdzi, ĝe ograniczajÈ one kreatywnoĂÊ. Ludzie nieznajÈcy siÚ na programowaniu czÚsto nie zdajÈ sobie sprawy, ĝe programowanie jest procesem równie kreatywnym, co pisanie wierszy lub komponowanie muzyki. W kaĝdej z tych dziedzin sÈ pewne reguïy, których wypada siÚ trzymaÊ. W zaleĝnoĂci od tego, w jakiej konwencji piszemy wiersz, musimy zadbaÊ o to, by siÚ rymowaï, zachowywaï pewien rytm i miaï odpowiedniÈ liczbÚ zgïosek w wersie. Z programowaniem jest podobnie. Na podstawowym poziomie mamy do czynienia z pewnymi zasadami, które definiujÈ pole dziaïania. Standardy pisania kodu to tylko niewielki wycinek owych zasad. WciÈĝ jednak programista ma nieskoñczone moĝliwoĂci wykorzystania swojej kreatywnoĂci i pomysïowoĂci. Drugi mit to twierdzenie, ĝe standardy nie sÈ potrzebne. ProgramiĂci czÚsto mówiÈ: „Mój kod zawsze dziaïaï bez zarzutu, po co mi wiÚc standardy?” albo „Jeĝeli nie rozumiesz kodu, który piszÚ, to znaczy, ĝe jesteĂ za sïaby, by pracowaÊ nad tym projektem”. Takie stanowisko jednak nie odnosi siÚ do sedna sprawy. Standardy nie istniejÈ po to, by kod mógï dziaïaÊ (chociaĝ mogÈ siÚ do tego przyczyniÊ). Jest wiele innych narzÚdzi, które pomagajÈ uruchamiaÊ kod. Standardy majÈ uïatwiaÊ programistom czytanie wïasnego kodu i kodu napisanego przez innych. Druga z przytoczonych wypowiedzi zdradza nastawienie programisty do pracy w zespole. Moim zdaniem jest dokïadnie odwrotnie — im wiÚkszy zespóï i im bardziej zïoĝony projekt, tym wiÚcej korzyĂci dajÈ pewne podstawowe reguïy.

Standard pisania kodu PHP Istnieje wiele róĝnych sposobów definiowania standardu pisania kodu. Niektórzy preferujÈ uzgodniÊ jedynie podstawowe wytyczne i pozostawiÊ resztÚ programistom, inni wolÈ jednoznacznie okreĂlaÊ jak najwiÚcej rzeczy. Tak naprawdÚ nie ma idealnego sposobu. W okreĂlonej sytuacji lub danym projekcie kaĝdy standard moĝe siÚ sprawdziÊ lub nie.

19

PHP 5. NarzĊdzia dla ekspertów

MajÈc to na uwadze, trzymajmy siÚ jednak filozofii prezentowanej w tej ksiÈĝce i stwórzmy ogólny standard pisania kodu, którego bÚdzie moĝna uĝyÊ jako punktu wyjĂcia przy definiowaniu standardów dla konkretnych projektów. Zakïadamy, ĝe programujemy co najmniej w PHP5 i w konsekwencji nasz standard bÚdzie miÚdzy innymi zakazywaï stosowania pewnych konstrukcji i konwencji typowych w obiektowych implementacjach pisanych w PHP4.

Formatowanie Formatowanie nadaje ogólny wyglÈd kodowi. WïaĂnie ono stanowi o pierwszym wraĝeniu, kiedy patrzymy na kod. Jest to takĝe okazja do poprawienia czytelnoĂci kodu, która nie wymaga nawet od programisty dokïadnego rozumienia jego dziaïania.

Znaczniki kodu PHP Kod PHP musi byÊ ujmowany w rozwiniÚte wersje znaczników PHP: . Znaczniki skrócone () oraz znaczniki w stylu ASP () sÈ niedozwolone.

WciÚcia Tabulatory muszÈ zostaÊ zastÈpione czterema spacjami. WiÚkszoĂÊ Ărodowisk programistycznych i edytorów tekstowych da siÚ skonfigurowaÊ tak, aby robiïy to automatycznie.

DïugoĂÊ wierszy Sugerowana maksymalna dïugoĂÊ wiersza to 80 znaków, mimo ĝe wiÚkszoĂÊ edytorów dziaïajÈcych w Ărodowisku graficznym bez problemu akceptuje wiÚkszÈ ich liczbÚ. Konwencja ta uwzglÚdnia fakt, ĝe okna wiersza poleceñ czÚsto sÈ ograniczone do 80 znaków w wierszu. NajwiÚksza dopuszczalna liczba znaków w wierszu to 120. Dïuĝsze wiersze nie sÈ akceptowane.

Zakoñczenia wierszy Wiersze muszÈ koñczyÊ siÚ wyïÈcznie standardowym uniksowym znakiem koñca wiersza (LF). Znakowi temu odpowiada kod dziesiÚtny 10 lub szesnastkowy 0x0A. Znaki powrotu karetki (CR) (kod 0x0D) zwykle stosowane w komputerach Macintosh i kombinacje znaków powrotu karetki i koñca wiersza (CRLF) (0x00D, 0x00A) sÈ niedozwolone.

OdstÚpy Dla zachowania czytelnoĂci spacje sÈ wymagane w nastÚpujÈcych miejscach w kodzie:

20

Rozdziaá 1. • Standardy i styl pisania kodu

Q po przecinku bÚdÈcym separatorem listy parametrów metod, funkcji lub elementów

tablicy, Q po sïowach kluczowych struktur sterujÈcych, takich jak if, else, unless, switch itd., Q przed nawiasami klamrowymi (chyba ĝe nawias jest pierwszym znakiem w wierszu), Q przed operatorami logicznymi, takimi jak &&, ||, &, |, ==, !=, === oraz !==, Q przed operatorami arytmetycznymi i po nich, np. +, -, * oraz %, Q przed operatorami przyporzÈdkowania i po nich, np. =, +=, -+ oraz *=.

Instrukcje Dopuszczalna jest tylko jedna instrukcja w wierszu. Wstawianie kilku instrukcji w jednym wierszu zostaïo jednoznacznie zabronione, poniewaĝ czÚsto umykajÈ one uwadze podczas czytania kodu. Dzielenie jednej instrukcji na kilka wierszy nie jest zalecane, chyba ĝe wyraěnie poprawia czytelnoĂÊ kodu.

21

PHP 5. NarzĊdzia dla ekspertów

CiÈgi tekstowe CiÈgi tekstowe definiujemy za pomocÈ cudzysïowu, jeĝeli korzystamy z osadzania zmiennych lub ciÈg zawiera znaki formatujÈce albo apostrofy, czyli na przykïad: ',\n lub \t. We wszystkich innych przypadkach naleĝy uĝywaÊ apostrofów, poniewaĝ nie obciÈĝajÈ one tak interpretera i przyspieszajÈ wykonanie skryptów. CiÈgi o dïugoĂci przekraczajÈcej maksymalnÈ dïugoĂÊ wiersza powinny byÊ dzielone na krótsze segmenty ïÈczone ze sobÈ za pomocÈ notacji z kropkÈ. W przypadku dïugich ciÈgów naleĝy w miarÚ moĝliwoĂci korzystaÊ z notacji heredoc.

Tablice Tablice indeksowane numerycznie powinny mieÊ w miarÚ moĝliwoĂci indeksy rozpoczynajÈce siÚ od zera. W definicjach tablic dopuszcza siÚ kilka elementów na wiersz, ale nastÚpne wiersze muszÈ byÊ wyrównane spacjami z elementami w pierwszym wierszu.

22

Rozdziaá 1. • Standardy i styl pisania kodu

Tablice asocjacyjne naleĝy deklarowaÊ po jednej parze klucz-wartoĂÊ na wiersz. Za pomocÈ spacji naleĝy wyrównaÊ ze sobÈ nazwy, operatory przyporzÈdkowania i wartoĂci w kolejnych wierszach. Jeĝeli wartoĂciÈ klucza jest ciÈg, naleĝy zawsze ujmowaÊ jÈ w apostrofy.