Siedem błędów podręcznikowych Wprowadzenie
Jedna z największych cech pozytywnych PHP jest także jego największą słabością: PHP jest łatwe do nauki. Przyciągnęło to mnóstwo ludzi nie zdających sobie sprawy, że znacznie trudniej jest się nauczyć, jak to zrobić dobrze.
Po prostu do tej pory nie był kładziony wystarczający nacisk na praktykę dobrego programowania. Niedoświadczeni programiści byli zatrudniani do tworzenia i wdrażania skomplikowanych aplikacji sieciowych. Wszędzie w nich są błędy, których uniknęliby doświadczeni koderzy, takie jak błędne użycie funkcji printf() lub błędne stosowanie semantyki PHP.
W tej trzyczęściowej serii artykułów pokażę 21 często popełnianych błędów - od raczej błahych do tych, które mogą spowodować załamanie systemu. Przedstawię też ich rozwiązania, sugestie i/lub komentarze jak je rozwiązać i unikać ich oraz kilka zawodowych sztuczek, jakich nauczyłem się przez lata swojej praktyki.
Seria składa się z trzech następujących artykułów:
Część 1: Obejmuje 7 pierwszych, "podręcznikowych" błędów (#21-15, w kierunku od najmniej poważnych do tych najgorszych na naszej liście rankingowej). Popełnienie jednego z tych błędów, mimo, że nie są one krytyczne, doprowadzi do spowolnienia kodu i trudno ci w jego konserwacji (utrzymywaniu).
Część 2: Obejmuje 7 kolejnych "poważnych" błędów, reprezentujących numery 14-8 na naszej liście rankingowej. Popełnienie jednego z tych błędów prowadzi do drastycznego spowolnienia wykonywania kodu, zmniejszenia jego bezpieczeństwa i kłopotów w konserwacji skryptów.
Czę ć 3: Obejmuje ostatnich 7 "śmiertelnych" błędów. Są to błędy koncepcyjne (pojęciowe, rozumowe) i mogą być przyczyną popełniania błędów wymienionych w części I i II. Zaliczają się do nich takie gafy jak przydzielenie zbyt mało czasu na projekt i brak dostatecznej kontroli kodu.
21. Niewłaściwe użycie printf Funkcja printf() w zamierzeniu ma być używana do wyświetlania sformatowanych danych.
Powinna ona być użyta, na przykład, kiedy potrzebujesz wyświetlić liczbę typu double z dokładnością do dwóch miejsc po przecinku lub w jakimś innym przypadku, kiedy chcesz zmienić format wyjścia przed jego wyświetleniem.
W poniższym przykładzie pokazano poprawne użycie funkcji printf(). Jest ona użyta do sformatowania wartości M_PI do żądanej precyzji:
<?php /* * Trzy twarze Π */ printf ("Pi wynosi: %.2f <br> ", M_PI); printf ("Pi wynosi także: %.3f <br> ", M_PI); printf ("Pi wynosi także: %.4f <br> ", M_PI); ?> Uwaga: Widziałem już przypadki, kiedy ludzie mieli printf()-ofobię, pisząc własne funkcje do formatowania danych wyjściowych, czasem długie na 30-40 wierszy, podczas gdy jedno wywołanie funkcji printf() zrobiłoby całą robotę za nich.
Wielu programistów niewłaściwie używa funkcji printf() przez stosowanie jej do wyświetlania zmiennych, wyników wywoływania funkcji lub czasami po prostu zwykłych danych. Nadużycia takie najczęściej zdarzają się w następujących okolicznościach:
Kiedy konstrukcja print() jest właściwsza.
Przy wyświetlaniu danych zwracanych przez funkcję.
Kiedy print() jest właściwsze
Programiści często używają funkcji printf() tam, gdzie wystarczyłby zwykły print(). W poniższym przykładzie printf() jest użyty od wyświetlenia czterech zmiennych:
<?php $nazwisko = 'Sterling Hughes'; $stanowisko = 'Senior Engineer'; $firma = 'DesignMultimedia'; $email = 'shughes@designmultimedia.com'; printf ("Moje nazwisko to: %s <br> Moje stanowisko to: %s, %s <br> Mój E-mail: %s <br> ", $nazwisko, $stanowisko, $firma, $email); ?> Zamiast tego mógłby być użyty print() w sposób jak poniżej:
print "Moje nazwisko to: $nazwisko <br> Moje stanowisko to: $stanowisko, $firma <br> Mój E-mail: $email <br> ";
Użycie print() zamiast printf() wtedy, gdy nie musisz formatować danych wyjściowych, tak jak w powyższym przykładzie, ma następujące zalety:
Większa wydajność:
Funkcja printf() przed wyświetleniem danych formatuje je. Dlatego zabiera to więcej czasu niż wykonanie instrukcji print() lub echo().
Bardziej przejrzysty kod:
Powiedzmy to wprost, używanie funkcji printf() wprowadza nieco zamieszania dla ludzi czytających kod (chyba że w przeszłości programowali w C). Wymaga to zarówno znajomości składni printf(), (tj. że %s oznacza string podczas gdy %d oznacza cyfrę/liczbę dziesiętną), jak i znajomości typów by printf() nie pomieszał wyników.
Używanie printf() do wyświetlania wartości zwracanych przez funkcję.
Innym powszechnym błędem jest używanie printf() do wyświetlania wartości zwracanych przez funkcję, co pokazuje poniższy przykład funkcji count:
<?php printf ("Znaleziono %d wystąpień %s .", count($wynik), $szukany_string); ?> Dla wyświetlania danych wyjściowych funkcji powinien być używany operator . (kropka) w połączeniu z print(), co pokazuje poniższy przykład:
<?php print "Znaleziono" . count($wynik) . " wystąpień of $szukany_string."; ?>
Operator . (kropka) dołącza wynik wywołania funkcji do tekstu, który chcesz wyświetlić. Użycie go umożliwia uniknięcie stosowania wolniejszego printf(). Powodem, jak już wspomniałem, jest to, iż próbuje on sformatować dane przed ich wyświetleniem na ekranie.
20. Błędne stosowanie semantyki Wielu programistów używa PHP bez pełnego zrozumienia pewnych mniej oczywistych cech tego języka. Jednym z nich jest różnica między składnią PHP i semantyką PHP.
Składnia PHP: Reprezentuje zbiór zasad do definiowania elementów PHP. Na przykład, jak definiujesz zmienne? Umieszczasz $ przed słowem będącym nazwą zmiennej; jak definiujesz funkcję? Ogólnie mówiąc, używasz nawiasów i argumentów, itd...
Semantyka PHP: Reprezentuje zbiór zasad do zastosowania składni. Na przykład, weźmy funkcję wymagającą 2 argumentów tak jak to zdefiniowano przez jej składnię. Jednakże, oba argumenty powinny być stringami to jest semantyka. Zauważ sposób w jaki mówimy "powinny". W językach opartych na ścisłym definiowaniu typów, takich jak Java lub C nie ma żadnych "powinny" (z pewnymi wyjątkami). Kompilator zmusi Cię do użycia takiego typu, jak podano w definicji funkcji.
Jednakże, w językach opartych na luźnym przypisywaniu typów, takich jak PHP, masz większą swobodę w formułowaniu wyrażeń.
Mimo wszystko, dla większości zdefiniowanych funkcji PHP powiniene oczekiwać błędu w przypadku odstąpienia od zdefiniowanej wcześniej semantyki.
Rozważ następujący przykład otwierania pliku i wyświetlenia wszystkich jego wierszy:
<?php $fp = @fopen ('jakisplik.txt', 'r') or die ('Nie moge otworzyc jakisplik.txt'); while ($line = @fgets ("$fp", 1024)) // blad { print $line; } @fclose ("$fp") // blad or die ('Nie moge zamknac jakisplik.txt'); ?> Powyższy przykład wygeneruje komunikaty o błędach takie jak:
"Warning: Supplied argument is not a valid File-Handle resource in C:Inetpubwwwroot st.php on line 4."
Wszystko przez to, że zmienna $fp została przekazana w podwójnym cudzysłowiu co sprawiło, że stała się stringiem. Jednakże, funkcja fopen() jako pierwszego argumentu spodziewa się identyfikatora zasobu a nie stringa. Musisz utrzymać typ tego argumentu jako identyfikatora zasobu.
Uwaga: Ten string, jednakże, był poprawny syntaktycznie. Aby naprawić ten błąd po prostu pozbąd się podwójnych cudzysłowów:
<?php $fp = @fopen ('jakisplik.txt', 'r') or die ('Nie moge otworzyc jakisplik.txt'); while ($line = @fgets ($fp, 1024)) { print $line; } @fclose ($fp) or die ('Nie moge zamknac jakisplik.txt'); ?> Ale czy mogą Ci ujść na sucho błędy semantyczne?
Nasz przykład powyżej wygenerował błąd. Ale PHP daje Ci możliwość własnego skonfigurowania skryptów tak, by były zgodne z unikalnym scenariuszem lub wymogami danych wyjściowych. Jest więc, przynajmniej teoretycznie możliwe, że błędne stosowanie semantyki "ujdzie Ci na sucho".
Z tego względu, jeśli zamierzasz igrać z semantyką PHP bądź świadom możliwych rezultatów. Niewłaściwe jej używanie może powadzić do generowania błędów, jeśli nie będziesz dość ostrożny.
Jeśli chcesz indywidualizować swoje skrypty musisz być pewny, że rozumiesz następujące kluczowe tematy:
Typy: W PHP, każda zmienna ma zdefiniowany typ w każdy momencie wykonywania kodu. Jest tak mimo tego, że jej typ można dowolnie konwertować. Innymi słowy: zmienna PHP nie będzie istniała bez jakiego zdefiniowanego typu (wraz z charakterystyką tego typu). PHP zawiera 7 podstawowych typów danych: logiczny, zasób (resource), całkowity, zmiennoprzecinkowy podwójnej precyzji, string, tablica i obiekt.
Zakres: W PHP, każda zmienna ma swój zakres ważności. Zakres zmiennej określa miejsca, gdzie można się do nich odwoływać (cały skrypt, określona funkcja itp. - przyp. tłum.) oraz czas jej życia. Niezrozumienie pojęcia "zakresu", może prowadzić zarówno do drobnych pomyłek jak i poważnych błędów.
php.ini: Podczas pisania skryptów, które mają być przenośne ważne jest zrozumienie, że nie wszyscy użytkownicy mają taką samą konfigurację PHP jak Ty. Stąd konieczna jest kontrola ustawień w kodzie by upewnić się, że dany skrypt będzie prawidłowo działał w bieżącej konfiguracji.
19. Niedobór dokumentacji w kodzie Słabo udokumentowany kod źródłowy jest, moim zdaniem, wynikiem programowania "dla siebie". Może to prowadzić do nieprawidłowych poprawek, błędnie interpretowanych znaczeń poszczególnych elementów kodu oraz poważnego bólu głowy osoby czytające taki skrypt. Generalnie mówiąc, wewnętrzną dokumentację kodu uważa się za rzecz bardzo potrzebną, ale rzadko obecną.
Znany jest także problem zbyt obfitej dokumentacji. Na szczęście występuje rzadko a jego niekorzystne oddziaływanie polega na zaśmiecaniu kodu źródłowego i zmniejszaniu jego czytelności.
Nadmiar dokumentacji przedstawia poniższy przykład:
<?php // Poczatek kodu PHP $wiek = 18; // przypisanie 18 do wieku $wiek++; // zwiekszenie $wiek o jeden // pokaz tekst wprowadzajacy print "Teraz masz 19 lat, co oznacza ze do tej pory miales :"; print " <br> <br> "; // Petla for do wydrukowania wszystkich poprzednich lat for ($idx = 0; $idx < $wiek; $idx++) { // Wyswietla pojedynczy wiek print "$idx lat <br> "; } // Koniec kodu PHP ?> Ile dokumentacji?
W jakich więc granicach dodawać komentarze do skryptu? Może to zależeć od wielu rzeczy takich jak budżet projektu, polityki firmowej, złożoności skryptu itp. Jest jednak kilka ogólnych wskazówek których powiniene przestrzegać niezależnie od tego, jaki masz własny styl dokumentowania kodu:
Zawsze przed funkcją umieszczaj krótki opis jej celu i sposobu działania.
Dodawaj komentarze tam, gdzie wykorzystujesz jakie haczyki lub gdzie kod wydaje się błędny mimo, iż w rzeczywistości działa poprawnie.
Jeśli jakiś kawałek kodu wygląda myląco, dodaj małą notatkę dotyczącą jego działania. Będziesz sobie za to dziękował w przyszłości.
Używaj konsekwentnego stylu komentowania, zdecyduj się albo na /* */ albo na // (unikaj raczej komentarzy #).
Poniżej znajduje się dobry przykład komentowania kodu:
<?php // Random_Numbers.lib // Generate different types of random numbers. mt_srand((double)microtime()*1000000); // // mixed random_element(array elements[, array weights]) // Extract a random element from elements. Weights is // the relative probability that each element will be // selected. // function random_element ($elements, $weights=array()) { // There must be exactly the same amount of elements as // there are weights for this algorithm to work properly if (count ($weights) == count ($elements)) { foreach ($elements as $element) { foreach ($weights as $idx) { // Note: we don't use $idx, since we // don't want to override elements. $randomAr[] = $element; } } } else { $randomAr = $elements; } $random_element = mt_rand (0, count ($randomAr)-1); return $randomAr[ $random_element ]; } ?> 18. Zbyt wiele zmiennych, zbyt wiele czasu Niektórzy ludzie mają całkowitą obsesję na punkcie zmiennych tymczasowych. Ja po prostu nie mogę zrozumieć rzeczy wyglądających w ten sposób:
<?php $tmp = date ("F d, h:i a"); /* ie January 3, 2:30 pm */ print $tmp; ?> Po co ta zmienna tymczasowa? Ona po prostu nie jest potrzebna:
<?php print date ("F d, h:i a"); ?> Niestety, wygląda na to, że wielu użytkowników ma kłopoty z zerwaniem z tym złym nawykiem. Zmienne tymczasowe spowalniają wykonywanie programu. Będzie szybciej, je li się je wszystkie pominie i zbierze razem wywołania funkcji. Użytkownicy stosujący zmienne tymczasowe często dodają aż 25% czasu wykonywania swoich skryptów.
Innym powodem unikania stosowania zmiennych tymczasowych jest to, że po prostu nie wyglądają one elegancko. Który z powyższych przykładów jest bardziej zwięzły - ten z dodatkową zmienną czy bez? Który z nich jest przyjemniejszy dla oczu? Stosowanie zbyt wielu zmiennych tymczasowych może doprowadzić do zmniejszenia czytelności kodu i jego zwięzłości.
Pozytywne przykłady użycia dodatkowych zmiennych.
Zmienne tymczasowe są użyteczne do zastępowania długich wywołań funkcji lub wyrażeń. Mogą służyć jako pewnego rodzaju alias. Ma to zastosowanie zwłaszcza wtedy, gdy musisz korzystać z tej funkcji lub wyrażenia wiele razy.
Spójrz na poniższy przykład w którym wykorzystano tylko tyle zmiennych, ile to naprawdę konieczne:
<?php // string reverse_characters(string str) // Reverse all of the characters in a string. function reverse_characters ($str) { return implode ("", array_reverse (preg_split("//", $str))); } ?> Zawartość (argumenty wywołania - przyp. tłum.) funkcji implode jest dość długa i z tego powodu trudna w odczycie. Użycie jednej lub więcej funkcji tymczasowej może znacznie uprościć sprawę:
<?php // string reverse_characters(string str) // Reverse all of the characters in a string. function reverse_characters ($str) { $characters = preg_split ("//", $str); $characters = array_reverse ($characters); return implode ("", $characters); } ?> Reguły ogólne
Kiedy musisz zdecydować czy użyć zmiennych tymczasowych czy też nie, zadaj sobie 2 następujące pytania:
Czy będziesz używał tej zmiennej przynajmniej dwa razy?
Czy czytelność kodu zwiększy się w znaczący sposób?
Jeśli otrzymasz odpowiedź twierdzącą na co najmniej jedno z tych pytań, zastosuj zmienną pomocniczą. W przeciwnym wypadku zapomnij o tym i połącz wywołania funkcji (jeśli to konieczne).
17. Przepisywanie istniejących funkcji PHP Pewne źródło wiedzy o PHP doradza zmianę nazwy istniejącej funkcji PHP po to, by uczynić ją łatwiejszą dla programistów VB przesiadających się na PHP:
<?php function len ($str) { return strlen ($str); } ?> Niektórzy użytkownicy upierają się przy przepisywaniu powszechnie znanych funkcji PHP zamiast nauczyć się tych funkcji, których dostarcza sam język.
Są co najmniej dwa powody, dla których należy potępić takie zachowanie. Przede wszystkim prowadzi to do zmniejszenia czytelności kodu. Ludzie czytający lub modyfikujący taki kod zobaczą mnóstwo (pozornie) niepotrzebnych funkcji które napisałeś i będą zastanawiać się po co je zdefiniowałeś w ten sposób zamiast użyć wbudowanych funkcji PHP.
Definiowanie własnych funkcji w ten sposób prowadzi także do spowolnienia wykonywania programu. Nie tylko więcej kodu musi zostać przetworzonego, ale też za każdym razem kiedy wywołujesz stworzoną przez siebie funkcję imitującą funkcję wbudowaną dodajesz pewną ilo ć czasu do narzutu czasowego spowodowanego wywołaniem funkcji.
Unikanie przepisywania istniejących już funkcji PHP.
Powiedzmy to sobie wprost - czasami ciężko tego uniknąć. W końcu programista nie musi znać wszystkich funkcji PHP, zresztą kto ma czas żeby to sprawdzać? Czemu po prostu nie przepisać?
Oto jak ja unikam przepisywania istniejących już w PHP funkcji - otóż wszędzie, gdzie piszę programy mam ze sobą kopie podręcznika PHP (używam indeksowanej wersji PDF). Następnie, jeśli mam zamiar napisać funkcję która "rozszerza" funkcjonalność PHP sprawdzam, czy taka funkcja już nie istnieje.
Jednakże, dzięki naturze otwartego kodu PHP możesz odkryć, że ktoś napisał funkcję zanim została ona włączona do PHP (jak np. znajdowanie różnic pomiędzy dwiema tablicami). W takim przypadku nie musisz od razu poprawiać swojego kodu.
16. Nie oddzielanie kodu wykonywanego po stronie serwera od tego wykonywanego po stronie klienta Niektórzy programiści mają w zwyczaju trzymanie całego kodu razem co oznacza, że kod HTML (czyli wykonywany po stronie klienta) oraz kod PHP (wykonywany po stronie serwera) znajdują się w jednym, wielkim pliku.
Podczas gdy można to jeszcze zaakceptować w przypadku małych witryn, prawdopodobnie stanie się to prawdziwym utrapieniem w razie rozbudowy strony i dodawania do niej więcej funkcji. Ten sposób programowania może prowadzić do powstania niemożliwego do konserwacji kodu i nieporęcznych plików.
Funkcje API
Mamy do wyboru kilka opcji jeśli chodzi o oddzielenie kodu klienta i kodu serwera. Jedną z metod jest utworzenie funkcji wyświetlających generowaną dynamicznie zawartość i umieszczenie tych funkcji we właściwym miejscu na stronie.
Ilustruje to poniższy przykład:
index.php kod wykonywany po stronie klienta <?php include_once ("site.lib"); ?> <html> <head> <title> <?php print_header (); ?> </title> </head> <body> <h1> <?php print_header (); ?> </h1> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td width="25%"> <?php print_links (); ?> </td> <td> <?php print_body (); ?> </td> </tr> </table> </body> </html> site.lib kod wykonywany po stronie serwera <?php $dbh = mysql_connect ("localhost", "sh", "pass") or die (sprintf ("Cannot connect to MySQL [%s]: %s", mysql_errno (), mysql_error ())); @mysql_select_db ("MainSite") or die (sprintf ("Cannot select database [%s]: %s", mysql_errno (), mysql_error ())); $sth = @mysql_query ("SELECT * FROM site", $dbh) or die (sprintf ("Cannot execute query [%s]: %s", mysql_errno (), mysql_error ())); $site_info = mysql_fetch_object ($sth); function print_header () { global $site_info; print $site_info->header; } function print_body () { global $site_info; print nl2br ($site_info->body); } function print_links () { global $site_info; $links = explode (" ", $site_info->links); $names = explode (" ", $site_info->link_names); for ($i = 0; $i < count ($links); $i++) { print " <a href="$links[$i]">$names[$i]</a> <br> "; } } ?> Jak widzisz, oddzielenie kodu klienta od kodu serwera dodaje kodowi czytelności. Innym plusem takiego rozwiązania jest to, że kiedy już masz funkcje GAPI wyświetlające dane, możesz pozwolić projektantom zmienić układ strony bez wymaganej zmiany kodu
Zalety funkcji GAPI
Względnie przejrzyste
Szybkie, prawie bez narzutu czasowego
Wady
Nie tak przejrzyste i łatwe jak system szablonów
Wymagają znajomo ci PHP do zmiany szablonu
System szablonowy
Innym sposobem oddzielenia kodu klienta od kodu serwera jest użycie systemu szablonowego. Polega to na użyciu znaczników szablonu, następnie przy parsowaniu pliku każdy taki znacznik zastępowany jest odpowiednimi danymi.
Na przykład mógłby mieć taki plik:
<html> <head> <title>%%PAGE_TITLE%%</title> </head> <body %%BODY_PROPERTIES%%> <h1>%%PAGE_TITLE%%</h1> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td width="25%">%%PAGE_LINKS%%</td> <td>%%PAGE_CONTENT%%</td> </tr> </table> </body> </html>
Mógłby potem napisać kod, który parsuje plik i zamienia dane wewnątrz znaczników %% tymi właściwymi.
Uwaga: dobrze napisana klasa do obsługi szablonów znajduje się pod adresem www.thewebmasters.net.
Zalety systemu szablonowego
Maksymalnie przejrzysty kod
Nie wymaga znajomości PHP do modyfikacji szablonu
Wady
Wolniejsze; musisz parsować cały plik szablonowy i dopiero po tym możesz go wyświetlić
Bardziej skomplikowana implementacja
15. Używanie przestarzałych konstrukcji i zwyczajów Wielu użytkowników zdaje się wciąż używać tego samego przestarzałego kodu i bibliotek. Na przykład napisali sobie jaką funkcję w PHP 2 i używają jej do tej pory, pomimo, iż taka funkcja została dodana już w PHP 3.
Używanie przestarzałych konstrukcji może zarówno zwolnić skrypt, jak i powodować jego nieczytelność. Czytelnicy Twojego kodu nie muszą być przecież zaznajomieni ze starymi, nieużywanymi już funkcjami PHP. Nie oznacza to oczywiście, że natychmiast po znalezieniu jakiegoś kawałka starego kodu musisz go natychmiast zmienić - po prostu nie używaj go już w przyszłości.
Przykładem takiej przestarzałej konstrukcji, czego wielu programistów nie może pojąć, jest składnia beginControlStructure .. endControlStructure;:
<?php // Stary, niewła ciwy kod while (1): print "5"; if ($idx++ == 5): break; endif; endwhile; // Lepsze podejście // (mimo że kod mógłby być zoptimalizowany) while (1) { print "5"; if ($idx++ == 5) { break; } } ?> Jest to złe podejście z kilku powodów:
Nie jest to szeroko rozpowszechnione, stąd wielu ludzi uczących się języka może zostać zmylone przez podwójną składnię
Nie jest to zgodne z innymi językami co oznacza, że trudniej to czytać ludziom przechodzącym na PHP
I co najbardziej istotne, pewnego dnia może to być wyłączone z języka, zmuszając Cię do przepisywania całego kodu. Natomiast nawiasy zawsze będą częścią PHP.
Powyższy przykład to tylko jedna z przestarzałych konstrukcji widziana przeze mnie w wielkiej ilości programów. Jest ich więcej. Regułą powinno być pisanie w stylu prezentowanym przez podręcznik PHP. W większości przypadków jest on aktualny i używa najnowszych funkcji w przedstawionych przykładach. Jeśli rozważasz rozszerzenie funkcjonalności PHP we własnym zakresie, najpierw sprawdź podręcznik. W ten sposób nie będziesz pisał funkcji, które napisał już kto inny, być może lepiej.
Podsumowanie W artykule tym przebiegliśmy przez pierwszych 7 z 21 błędów popełnianych przez programistów PHP. Tymi podręcznikowymi błędami są:
Niewłaściwe używanie funkcji printf(): powinna ona być stosowana wyłącznie wtedy, gdy musisz sformatować dane wyjściowe.
Błędne stosowanie semantyki: Wielu użytkowników nie poświęca należytej ilości czasu na zrozumienie pewnych niuansów semantyki PHP co owocuje powstaniem zabugowanego kodu ze skłonnością do generowania błędów.
Niedobór dokumentacji w kodzie: Zawsze dokumentuj swój kod. Umieść komentarz przed każdą funkcją wymieniając jej parametry i cel. Pamiętaj także o wyjaśnieniu szczególnie skomplikowanych części kodu lub fragmentów zawierających jakieś sztuczki lub haczyki.
Używanie zbyt wielu zmiennych tymczasowych: Zmienne pomocnicze mogą być używane do zastąpienia wielokrotnych wywołań funkcji lub do skrócenia wywołań zagnieżdżonych.
Przepisywanie istniejących już funkcji: Zawsze sprawdź w podręczniku czy taka funkcja już nie istnieje zamiast od razy zabierać się do jej pisania.
Nie oddzielanie kodu wykonywanego po stronie serwera od tego wykonywanego po stronie klienta: Spróbuj podzielić swój kod na funkcjonalne i jednorodne moduły. Sprawi to, że program stanie się znacząco łatwiejszy w czytaniu oraz umożliwi zmianę części odpowiedzialnej za wygląd bez konieczności zmiany kodu działającego "w tle".
Używanie przestarzałych konstrukcji: To, że w PHP można co zrobić nie znaczy, że należy to robić. Zajrzyj do podręcznika i innych książek by zobaczyć, jak to zrobić we właściwy sposób (doskonałymi książkami są PHP4 Aplikacje oraz Professional PHP) (ta druga chyba jeszcze nie została wydana w Polsce, przynajmniej ja nic o tym nie wiem - przyp. tłum.).
O autorze
Sterling Hughes niezależnym webdeveloperem tworzącym dynamiczne witryny dla kilku największych korporacji na wiecie. Jest autorem rozszerzeń cURL i SWF od PHP oraz książki The PHP Developer's Cookbook (w oryginale wydana przez Sams, o polskim wydaniu nie słyszałem - przyp. tłum).
