Trup w szafie - poprawność kodu PHP Opcje

[hombrerro]

Od jakiegoś czasu współpracuje z dość dużą firmą hostingową, chyba ogólnie znaną. Praca polega na przepisaniu autorskiego (tzn. powstalego wlasnie w tej firmie) kodu systemu administracji kontami użytkowników. Dostałem konto na specjalnym developersko-testowym serwerze będącym "kopią serwera produkcyjnego" z opcjami "developerskimi". Opcja developerska polegała na włączeniu wyświetlania błędów na ekran a nie ich logowaniu.

Tyle tytułem wstępu.

Jak na serwer testowy monitowanie tylko o błędach typu E_ERROR jest dość odważnym posunięciem a tak właśnie było ustawione. Nikomu z wesołych programistów z firmy to najwyrazniej nie przeszkadzalo.
Ja jednak poszukałem dziury w całym, szczególnie po wstępnej analizie kilku plików, i wyprosiłem zmianę ustawień serwera.
Warningi i notice zajmowały srednio na kazdej ze stron około 2 ekranów.

Tyle tytułem rozwinięcia.

Błędy typu E_NOTICE i E_WARNING to też są błędy w kodzie i to czasem poważne i groźne.
Jednak mało kto zwraca na to uwagę chociaż np. w innych językach tego typu błędy są traktowane jako krytyczne zatrzymujące wykonywanie kodu.
php swą popularność (zasłużoną) uzyskało właśnie dzięki uproszczeniu zasad programowania, nie ma kontroli typów zmiennych, deklaracji zmiennych, gospodarowania pamięcią itd. Każdy może przeczytać byle jaki "tutorial" w internecie i programować. Najczęściej php jest pierwszym językiem z jakim takie osoby się zetknęły.
I to jest właśnie bół. php moim zdaniem nie jest wcale dobrym językiem dla początkujących gdyż nie narzuca ścisłych zasad programowania, nie wymaga "sterylności" kodu. Jaki procent osób piszących skrypty php przejmuje się np. wykorzystaniem zasobów systemowych? W php można olewać pewne reguły i wszystko działa na "stronce". I działa i działa i działa, pojawiają się nowe rozwiązania: bazy danych, szablony, CMSXFCPSy czy cokolwiek a nawyki a właściwiie ich brak zostają na zawsze. I są tak zwanym trupem w szafie.
Później tak się życie potoczy, że może trzeba będzie zrobić coś poważniejszego, jakąś "profeskę". Oczywiście zostanie zrobione, nawet fajnie będzie wyglądać...
I nawet będzie działać, tylko ( życie się toczy ) że wkrótce z aplikacji zacznie korzystać 100 razy więcej osób niż się to zakładało i zaczną się schody. Bo wszystko zacznie się sypać, zapychać, zawieszać, zapętlać a serwer zacznie umierać.

Przykład "systemu administracji" pokazuje to wszystko w praktyce.
I tak:
inkrementowane zmienne nie mają początkowej wartości ( a co najśmieszniejsze ta sama zmienna jest używana kilkakrotnie w module i jest inkrementowana od niewiadomo jakich wartości. Jedna z takich praktych powodowała błąd widoczny dla użytkowników)
- zmienne pochodzące z tablic $_POST, $_GET, $_COOKIE są ledwo co sprawdzane - zakłada się tylko, że zmienna jest albo jej nie ma. To są jedyne dwa stany istniejące w świadomości programistów.
- indeksy w tablicach są stałymi: $tablica[cos_tam]
- funkcje coś robią ale nie wiadomo czy im się udało
- itd.

Ale niestety nie jedyny przykład. Jakiś miesiąc temu instalowałem gdzieś system CMS - zdaje się że było to Envolution - też pojawiło się pare takich "gniotów" choć poziom zdecydowanie wyższy (i tu jest to chyba nieuwaga a nie olewactwo).

Dodatkowo dzisiaj ściągnąłem sobie ze strony php.skryptoteka.pl kilka okazów - no i to już jest "wolna amerykanka", oprócz kilku wyjątków, bałagan totalny. A najgorsze jest to, że ktoś sobie napisze "prosty licznik odwiedzin" który działa chyba tylko dlatego, że ma szczęście, wydali go do sieci z której pobierze go 1000 osób i wszyscy będą już "prosty licznik odwiedzin" mieli za sobą. A autor takiego oprogramowania zyska poważanie w środowisku (1000 downloadów).

Przepraszam jeżeli kogoś znudziłem ale postanowiłem dać upust swoim frustracjom spowodowanym poprawianiem bylejakiego kodu od patrzenia na który aż oczy bolą.
Wysłałem ten post na forum PRO bo uważam, że poprawne kodowanie jest największym profesjonalizmem. Myślę, że powinno się na to zwracać uwagę wielu osobom korzystającym z tego portalu - szczególnie początkującym. A tak przy okazji: fajnie w sumie, że tak gęsto i często odsyłacie błądzących do manuala może gdyby zapoznać się z nim a nie z tutorialem w sieci jakość kodu trochę by się podniosła.

[sobstel]

bardzo ładnie powiedzianie. myślę, że powinno to nawet zostać rzucone na portal php.pl jako jakiś news czy nawet krótki artykuł (albo uzupełnienie artu o standardów kodowania).
jak dla mnie pisanie w php jest jak pisanie w htmlu/css (w bardzo glebokim uogolnieniu rzecz jasna): napisanie czegokolwiek co jakos dziala (albo raczej stwarza takie pozory na komputerze piszącego) jest badzo latwo i moze to kazy po kilku gdozinach siedzenia z jakims tutorialem, jednak napisanie czegoś dobrego co NAPRAWD działa dobrze (+ jest bezpieczne, łatwe do rozbudowy itp), to dopiero prawdziwa sztuka... ;-)

[.dragonfly]

Bardzo duza wage przywiazuje do czystosci i sterylnosci kodu, nie pozwalam sobie nawet na bledy typu E_NOTICE. Robienie czegos "na sztuke" jest moim zdaniem totalna glupota. Jesli ktos tylko ze wzgledu na lenistwo nie dba o tego typu szczegoly niech lepiej wogole nie bierze sie za pisanie. Ktos sciaga skrypt i mysli ze jest super, nie daj boze uczy sie na jego podstawie i mamy kolejnego czlowieka ktory bedzie przez nastepne kilka miesiecy pisal "shitty code".

[shima]

Nabycie dobrych przyzwyczajeń wymaga napisania setek/tysięcy/dziesiątków tysięcy* linijek kodu i wielu popełnionych błędów. Ja napisałem już sporo w php, a nadal większość moich postów umieszczam na "php początkujący". A mam pewne doświadczenie, ponieważ dosyć długo juz programuję w c++ (i tu mogę powiedzieć, że początkujacym nie jestem). Takie błędy o jakich piszesz to wynikają z lenistwa, bałaganiarstwa, przeświadczenia o swoich umiejętnościach. I żaden to problem na tym forum, ale w przypadku tworzenia komercyjnego kodu już może być. Pamiętaj jednak, że wartość kodu weryfikuje rynek - ktoś chce kupić, to co za różnica co siedzi w środku? Działa i się sprzedaje.


* wybierz właściwą

[czachor]

Świetny tekst @hombrerro.
IMO wydaje mi się, że takie "programowanie" w php jest spowodowane głównie przez tutoriale, które w większości są odwalone, spełniają swoją podstawową funkcję - czyli "nauczą" kodować, natomiast nie ma w nich (prawie) słowa o tym, o czym napisałeś. Jeszcze chyba nie spotkałem (oprócz manuala ) kursu, który można by nazwać kursem z prawdziwego zdarzenia... Jak było o $_POST i pozostałych, to już było dobrze, a o error_reporting to jeszcze mi się nie trafiło

[shima]

Jeszcze chyba nie spotkałem (oprócz manuala ) kursu, który można by nazwać kursem z prawdziwego zdarzenia... Jak było o $_POST i pozostałych, to już było dobrze, a o error_reporting to jeszcze mi się nie trafiło

Trochę przesadziłeś albo mało czytasz. Brak wzmianki o raportowaniu błędów nie świadczy o tym, że tekst jest kiepski. Ważne, żeby był napisany zgodnie z regułami sztuki.

[czachor]

Trochę przesadziłem, fakt, ale chodziło mi właśnie o te "reguły sztuki". A takich tekstów dużo nie ma... (nie wciągając w to profesjonalnych stron oczywiście).

[pillot]

no a nie myślicie, że takie luzackie podejście do poprawności kodu jest wynikiem elastyczności php i jego ogólnodostępności/popularności? programować może każdy, leń, większy leń i programista (taki z prawdziwego zdarzenia). a jeśli dostanie w łapy coś takiego jak php to przecież nagina jak się da, żeby tylko szybciej i mniejszym wysiłkiem. ten język według mnie trochę "zachęca" do niechlujstwa, dlatego pisanie poprawnego kodu jest sztuką o tyle większą niż w innych językach, że wymaga samokontroli. nie powiem, ja sam mam jeszcze problemy z wieloma notice'ami w php ale się uczę i sukcesywnie poprawiam.

[Strzałek]

No dobrze. A jeżeli mam taki bardzo prosty skrypt:

[PHP] pobierz, plaintext 
<?
echo $_GET['a'];
?>
[PHP] pobierz, plaintext 

i wywołam go w przeglądarce to mi wywala:

Notice: Undefined index: a in c:\serwer\www\abcms\test.php on line 2

i teraz jak zrobic żeby tego nie było a jeżeli będzie przekazane coś metodą get (a) to żeby wyświetliło ?

Czy postawienie @ przed $ załatwi sprawę ?

[hombrerro]

Powinieneś najpierw sprawdzić czy jest wogóle coś takiego jak $_GET['a'] zanim zechcesz to wyświetlić. Możesz użyć funkcji np. isset() która sprawdzi czy dany indeks został ustawiony czyli istnieje.
Przy okazji możesz sobie ustawić defaultową wartość a.

[PHP] pobierz, plaintext 
<?php
 
   $a = isset( $_GET['a'] ) ? $_GET['a'] : 1;
 
?>
[PHP] pobierz, plaintext 

[Krolik]

Swietny tekst, @hombrerro. I na dodatek aktualny nie tylko dla php. Niestety sporo ludzi piszacych w innych jezykach tez cechuje takie olewactwo. O ile w php uchodzi to czesto plazem (php ma duzo roznych zabezpieczen takich jak np. "magic_squotes", a ostrzezenia mozna wylaczyc), to w C/C++/Pascalu moze miec oplakane skutki.

Przyklad: gosc uzywa wszedzie new, a nigdzie nie wstawia delete. Albo jako wejsciowe parametry funkcji uzywa wszedzie char* zamiast const char* i zeby "zamknac gebe kompilatorowi" uzywa jawnego rzutowania z (const char*) na (char*). Albo bezsensownie uzywa makrodefinicji, zeby skrocic kod.... Albo nazywa zmienne po swojemu, a nie tak jak przyjete w calym projekcie. I tabulatory wstawia tabem, a nie spacjami - wiec wciecia sie rozjezdzaja. O sprawdzaniu danych wejsciowych i obsludze bledow nie wspomne. Przykladow mozna by jeszcze mnozyc.

Mam takiego czlowieka w zespole. Te "grzechy" mozna byloby jeszcze wybaczyc, gdyby gosc mial troche pokory, ale nie: jak mu sie kaze cos poprawic, to owszem poprawi, ale za 10 minut znowu jest to samo w innym miejscu kodu. Dla niego to sa nieistotne "drobiazgi". Teraz projekt sie sypie przez bledy w jego kodzie. Bledy, ktore poprawia czasem i przez 2 dni (nikt inny nie jest w stanie ich poprawic, bo w kodzie nie ma jednego sensownego komentarza).

[shima]

(...) to w C/C++/Pascalu moze miec oplakane skutki.(...)

A testujecie czasem kod?

(...)Przyklad: gosc uzywa wszedzie new, a nigdzie nie wstawia delete.(...)

Co oczywiście łatwo da się wyłapać.

(...) Albo  bezsensownie uzywa makrodefinicji, zeby skrocic kod....(...)

Zapewne człowiek zaczynał przygodę z C? Bo W C++ zaleca się nie używać makrodefinicji. Może poza dyrektywami kompilacji warunkowej...

(...)Albo nazywa zmienne po swojemu, a nie tak jak przyjete w calym projekcie.(...)

Po to są przestrzenie nazw, zeby mógł "swoje" zmienne nazywać jak chce, a jeżeli uzgodnione, ze użyję terminologii php, superglobalne zmienne nazywa jak chce, to już nie jest niechlujstwo.

(...)I tabulatory wstawia tabem, a nie spacjami - wiec wciecia sie rozjezdzaja.(...)

Piszecie w notatnikach? Przecież są edytory i autoformatowanie.

(...)Mam takiego czlowieka w zespole.(...)

Albo to syn szefa, albo Wasz zespół to kółko programistyczne. Kto chce pracować z takim gościem?

[patrycjusz]

no to pozwole się wtrącić
co do kodu autorstwa mojej firmy sądze że raczej nic poważnego nikt nam nie zarzuci
ale mam właśnie ostatnio doczynienia z takim kodem jaki opisał autor tematu, ba
nawet bałagan tam jest większy a serwis liczy miliony odsłon miesięcznie (średnio 5-7 mln), żadnych bardziej zaawansowanych mechanizmów, o jakimś keszowaniu nie wspomne, czy też o szablonikach, wszystko przemieszane na przemian (html/php/sql).
Długo się zastanawiałem jaka jest przyczyna takiego stanu rzeczy, i chyba już mam
Programista - nie - a dlaczego ma odpowiadać za coś co mu firma (projekt menedzer) każde skodować, i to najczęściej "na wczoraj" i chłopak zapierd.. jak wółka leśna, nie wiele mu płacą itd, ja bym się nie spuszczał nad takim rozwiązaniem i zrobił na szybko raz dwa i po sprawie,
Projekt Menedzer (w firmie sprzedającej rozwiązanie) - to właśnie on jest współ winny całej sytuacji, powinnien inaczej dzielić czas wśród pracowników, inaczej negocjować prace itd,
Dodatkowo firma która zamawiała oprogramowanie, no przepraszam bardzo czy przy zakupie rozwiązania za 200 tyś, robionego prawie rok, nie można wziąść dwóch nie zależnych malućkich firm (za 5 tyś) które by audytowały kod?
Tak więc moim zdaniem, w takich sytuacjach wina leży raczej pośrodku i trochę dalej od samego programisty, to PM ma obowiązek rozplanować prace tak aby było ok, i to firma zakupująca rozwiązanie ma obowiązek sprawdzić co kupuje.
Proponuję Hydepark nie php Pro
pzdr

[halfik]

hmm... a i owszem, ze roznego rodzaju skrypty na sieci to w wiekszosci smieci, a nie dobry kod, ale zupelnie nie rozumiem az tak wielkiego ogolnego obozenia. owszem, wiekszosc uwag trafne, ale dal przykladu: nie rozumiem po co dbac o pamiec w phpie? po pierwsze mamy na tyle potezne maszyny w dzisiejszych czasach, ze raczej nie ma potrzeby, no chyba ze faktycznie piszemy oprogramowanie pod serwis, co do ktorego przewiduje sie potezne obciazenia etc.

dalej: autor topica wspomnial o tym ze autorzy w temacie wymionego kodu sprawdzaja jedynie czy zmienna istnieje lub nie: w sumie to zalezy, czasem nie ma potrzeby sprawdzania wartosci danych z formatki etc. coz, zalezy od przypadku.

ogolnie w sprawie: czasem nie warto sprawdzac pewnych rzeczy, wszystki zalezy od kontekstu, jesli mamy 100% pewnosc ze nie musimy bo ... to po co?

co do obiektowki: zgadzam sie, po 5 latach kodowania strukturalnego w kilku jezykach tez w kocnu zaczalem bawic sie OOP, bo czlowieka krew zalewa jak n-ty raz pisze ten sam kod, no powiedzmy w 90-95% ten sam - grrrrrrrrr... ale z drugiej strony np. pisze dla roznych ludzi prace dyplomowe w phpie i nie sa to jacys specjalnie doswiadczeni programisci (dziwne nie ?), cos tam potrafia w C czy Delphi, ale jakbym pisal te prace w OOP, to wytlumaczenie tego co tam od czego jest etc. zajebloby mi dluugie tygodnie...

wszystko zalezy od kotekstu

[shima]

ale z drugiej strony np. pisze dla roznych ludzi prace dyplomowe w phpie

czyli pomagasz w popełnieniu przestępstwa?

[Krolik]

(...) to w C/C++/Pascalu moze miec oplakane skutki.(...)

A testujecie czasem kod?

Tak, testujemy. Tylko problem w tym, ze:
- W testach nie wszystko wychodzi.
- W danej chwili poprawnie dzialajacy, niedbale napisany kod moze spowodowac powazne problemy pozniej, jak sie cos dopisze, niekoniecznie w tym samym miejscu. Testy regresji to wylapuja, ale pamietaj, ze intensywne testowanie i poprawianie zbyt wielu bledow staje sie w pewnym momencie bardzo drogie, zwlaszcza ze jesli beta testy nie wchodza w gre, jest deadline, a produkt ma byc w 100% sprawny. To nie KDE, ktore moze sie przez kila miesiecy sypac, zanim osiagnie odpowiedni poziom stabilnosci.

(...)Przyklad: gosc uzywa wszedzie new, a nigdzie nie wstawia delete.(...)

Co oczywiście łatwo da się wyłapać.

Owszem, ale poprawic jest zwykle BARDZO ciezko.

(...)Albo nazywa zmienne po swojemu, a nie tak jak przyjete w calym projekcie.(...)

Po to są przestrzenie nazw, zeby mógł "swoje" zmienne nazywać jak chce, a jeżeli uzgodnione, ze użyję terminologii php, superglobalne zmienne nazywa jak chce, to już nie jest niechlujstwo.

Przestrzenie nazw nie rozwiazuja problemu. Nie chodzi o konflikty nazw globalnych, tylko o to, ze jesli masz fragment kodu korzystajacy np. z 2 roznych modulow pisanych przez 2 osoby to ten fragment ma niespojne nazewnictwo (bo wywoluje rozne funckje). Przez to staje sie nieczytelny. Poza tym nie ma czegos takiego jak "moja zmienna". Kod powinien byc tak napisany, zeby kazdy inny programista, ktory tego kodu nie pisal, mogl go zrozumiec bez analizowania przez tydzien.

(...)I tabulatory wstawia tabem, a nie spacjami - wiec wciecia sie rozjezdzaja.(...)

Piszecie w notatnikach? Przecież są edytory i autoformatowanie.

No wlasnie, a niektorzy nie potrafia / nie chca ustawic nawet odpowiednich opcji.

(...)Mam takiego czlowieka w zespole.(...)

Albo to syn szefa, albo Wasz zespół to kółko programistyczne. Kto chce pracować z takim gościem?

Nie - robimy wiekszy projekt na uczelni. Mysle, ze gdyby pracowal w naszej firmie, to bysmy go szybko oduczyli zlych nawykow. Poza tym tam robimy w Javie, wiec wielu rzeczy by nie byl w stanie zrobic (np. makrodefinicje, hehe).

Dodam, ze z ta obecna niefrasobliwoscia dot. uzycia pamieci to jest jakies przegiecie. Moze to jest OT, ale Oracle 10g potrzebuje co najmniej 750 MB RAMu, zeby go sensownie dalo sie zainstalowac. Masakra.

[halfik]

czyli pomagasz w popełnieniu przestępstwa?

nie nie, jakby ktos pytal to tylko sluze wspraciem w roli konsultanta

[xarr]

Ogolnie temat fajny i imo potrzebny. Sam piszac zwracam uwage na poprawnosc kodu, ktora mniej lub bardziej wplywa na wydajnosc badz bezpieczenstwo skryptu. Nie zawsze jednak tak bylo i podejrzewam, ze jest to normalny element nauki. Nie kazdy nauczywszy sie podstaw, pozbywa sie tych starych nawykow (srodkow) piszac powazniejsze rzeczy. Mysle ze przykladem moze byc tu podejscie wiekszosci webmasterow do htmla, czyli podstaw prezentacji danych na www. Widac tutaj jak ludzie chetnie "updatuja" info.... jak dziala to dziala, nie wazne jak. Mialem raz taki dosyc wyrazny przyklad jak witryne ladujaca sie w 5x sekund mozna zoptymalizowac niemal samym htmlem i css aby ladowala sie 60% szybciej. No, ale wracajac do tematu... mysle ze potrzebne sa informacje w polskim internecie na temat poprawnego pisania. Takie vademecum i wbrew pozorom najprawdopodobniej dotyczylo by to zaawansowanych koderow i takowi najwiecej by z tego wyniesli Czlowiek nigdy nie wie wszystkiego, a nawet siedzac w jednym jezyku lata, mozna sie naciac na swojej niewiedzy.
Mozna by stworzyc takie subforum albo moze nawet i dzial na stronce php.pl, ktory pelnil by role uswiadamiania ludzi o koniecznosci poprawnej pisowni kodu lub tez ewentualnym jego optymalizowaniu. Dosyc dlugo czytam juz to forum i www, i wiem ze nie lubi sie tutaj "latwizny i lenistwa". To dobrze, ale teksty czy nawet linki do tekstow oraz jakies krotkie przyklady mogly by trafic do wielu glow.
Oczywiscie jak to bywa w wiekszosci wypadkow latwo sie gada o tym by cos zrobic, cos zmienic, ze jest zle, ze niedobrze.... trudniej jednak stawac naprzeciw. Tak czy inaczej to bardzo ciekawy problem, a proby jego rozwiazania mogly by byc pouczajace takze dla samych "poprawnie" kodujacych.

Pozdrowka

Ten post edytował |[xarr]| 16.12.2004, 12:55:15

[bela]

poprawnosc kodu, ktora mniej lub bardziej wplywa na wydajnosc

przeprowadzono testy i kod bez żadnych białych znaków i komentarzy wykonywał się ~30% szybciej

[Vengeance]

tylko, że czasem te 30% to tak na prawde 0,3 sekundy ;]
I jak dla mnie to zbyt mały zysk aby o niego "walczyć"